For general information and resources, ITIL and ITSM World is the most well known for both ITIL and ITIL Books. A shorter snapshot approach can be found at ITIL Zone
Note: ® ITIL is a registered trademark of OGC. This portal is totally independent and is in no way related to them. See our Feedback Page for more information.
The Itil Community Forum: Forums
ITIL :: View topic - Forward Schedule of Change (FSC)
Posted: Thu Sep 28, 2006 11:21 pm Post subject: Forward Schedule of Change (FSC)
What does a FSC exactly contain, the period when a RfC ist going to be implemented, or only the Date of Release? Have seen some different approaches in books, I'd like your opinion on that know, thanks
Joined: Sep 16, 2006 Posts: 3189 Location: London, UK
Posted: Fri Sep 29, 2006 10:12 pm Post subject:
Fighter is correct
The objective of the FSC is to inform the recipients of the UPCOMING Changes which will be implemented in the next ....insert period ... and beyond.
There should be enough information in the FSC for the person reading to determine whether the change is going to affect them and to be able to view the change request in detail by having key data.
The Change Manager should field any questions from the recipients _________________ John Hardesty
ITSM Manager's Certificate (Red Badge)
Change Management is POWER & CONTROL. /....evil laughter
Joined: Jan 01, 2006 Posts: 500 Location: New Jersey
Posted: Sat Sep 30, 2006 5:53 am Post subject:
Hello Avalanche,
A Forward Schedule of Changes, is "Change-specific" not Release-specific, and is intended to highlight all related scheduled milestone dates associated with all Changes.
If you're moving your Changes through multiple environments, you will have things like (but not limited to):
- Expected Development Environment Deployment Date/Time
- Expected Development Environment Testing Start Date/Time
- Expected Development Environment Testing End Date/Time
- Expected QA Environment Deployment Date/Time
- Expected QA Environment Testing Start Date/Time
- Expected QA Environment Testing End Date/Time
- Expected Production Environment Deployment Date/Time
- Expected Production Environment Testing Start Date/Time
- Expected Production Environment Testing End Date/Time
- Expected Change "Close Date/Time"
This allows you to see expected activity in each environment as well as activity across them.
A Forward Schedule of Releases would do the same at a higher/coarser Release level, which usually indicates one or more Changes that have been grouped into a Release.
I hope this helps.
Regards, _________________ [Edited by Admin to remove link]
I look at the FSC as a list of single-tasked projects. So each RFC in my opinion is a small project containing a single task and all the relevant information from a project management perspective. These include the definition of the task, the owner, the start date, the end date, the acceptance testing of the project, and in some cases the procedure to be followed.
Joined: Sep 16, 2006 Posts: 3189 Location: London, UK
Posted: Mon Oct 02, 2006 12:55 am Post subject:
A Forward Schedule of Change should be only for an Operational IT Environment.
ITIL concentrates on IT and the services than IT (organization) provides to its consumers. ITIL does notcare really about Software Development and it only cares about Software Release management in the context of Release and Change Management ----> to the Operational world.
The FSC is supposed to keep people/team like the Service Desk, Monitoring teams, Service Managers & service Management, Problem & Incident Mgmt as well as Change, Release and Config mgmt aware of teh upcoming changes which may affect/impact the Service which is being provided. _________________ John Hardesty
ITSM Manager's Certificate (Red Badge)
Change Management is POWER & CONTROL. /....evil laughter
Joined: Jan 01, 2006 Posts: 500 Location: New Jersey
Posted: Mon Oct 02, 2006 2:23 am Post subject:
Hello UKVIKING,
Please see my comments, embedded below...
UKVIKING wrote:
A Forward Schedule of Change should be only for an Operational IT Environment.
Actually, the Developement, Systems Integration Testing, User Acceptance Testing, etc. are all "operational environements," too. And if you're in an enterprise that is smart about how they manage their Product Lifecycles, they will want Forward Schedule of Changes to map out how things are progressing across any and all environments. You build and "practice" in all of those operational environments, long before you get to the last operational environment, which is "Production".
Remember, "ITIL" is only about the Production operational environment. This is one of the many things that makes ITIL highly incomplete. Please do not follow it to the letter or assume it is the end-all-be-all of IT best practices. It is not.
Quote:
ITIL concentrates on IT and the services than IT (organization) provides to its consumers.
Actually, as stated above, ITIL only concentrates on the Production operations aspect of IT, which is a very small subset of what managing IT really means. So to say that it "concentrates on IT" is very innacurate. It leaves out planning, design, implementation, deployment, instantiation, execution, verification, financial accounting, and much, much more. It is far from complete and far from "concentrating on IT" as a whole picture.
Quote:
ITIL does notcare really about Software Development and it only cares about Software Release management in the context of Release and Change Management ----> to the Operational world.
Exactly, it "only" worries about very small areas of IT. NOTE: It also contradicts some other best practice specifications that developers and engineers are taught to follow at the front end of their design and development processes.
Quote:
The FSC is supposed to keep people/team like the Service Desk, Monitoring teams, Service Managers & service Management, Problem & Incident Mgmt as well as Change, Release and Config mgmt aware of teh upcoming changes which may affect/impact the Service which is being provided.
According to ITIL, yes. But because ITIL is limited and only worries about Production, it misses the fact that stakeholders in other environments (or across many environments) have their own work to worry about.
For example, if you a have QA department, where all products flow through it on the way to the production operations environment, the QA environment "is the operational environment" for the testers in QA. They want to see changes coming in or leaving it, just the same way you want to see changes coming into your production operations environment.
If you're forgetting about making their lives easier, in their QA operations environment and only worried about making your own easier, in your Production operations environment, then you may be missing a bigger picture. To them, they need an FSC for their QA operations environment, just as much as you do. As a matter of fact, it is based on their signoff that you will get your own FSC for the production operations environment.
It is for this reason that it is important to understand that a Request for Change (RFC) can cause a development effort that marches Changes through multiple environments. If this is the case, then you need to be able to plan for expected and actual dates/times for marching those changes across each and every environment... hence, an FSC that addresses each and every environment.
I hope this helps.
Regards, _________________ [Edited by Admin to remove link]
Joined: Sep 16, 2006 Posts: 3189 Location: London, UK
Posted: Mon Oct 02, 2006 4:43 am Post subject:
Frank
Please dont lecture me on ITIL. Also, stay on topic. This is the sub forum on Change Management in the Service Support portion of the ITIL processes.
The question was what is the Forward Schedule Change and the context I would assume is coming from a ITIL Service Support Change Management area.
There the answers I have so kindly given about the FSC in an IT Operational (HINT: Service Support) environment.
As a Change Manager, I did not give a hoot about the development cycle of any software or application or even the development cycle of hardware. Why ? Because until it is installed in a live environment, it does not affect the users of an IT service - which is the prime concern of the ITIL model - Service Support. - Hence the name Service Support.
While there are tools, processes, procedures, and policies surrounding the development of software, applications and hardware, it is not the concern of an IT Department which is supporting its users. It is a concern for the product manager, projetc managers, S/W & H/W developers and there are processes to handle any issue that may arise from the life cycle of S/W and H/W. ITIL Change Management is not one of them.
What we are talking about here is the Service Management aspects of ITIL - which is the 10 disciplines under Service Support & Service Delivery as well as the function - Service Desk.
And BTW, the 10 disciplines are Incident, Problem, Change, Release, Configuration, Availability, Continuity, Capacity, Service Level Management and Financial Management.
I dont know whether you have taken any ITIL courses; I have not seen any indications from you whether you have done so. So do not lecture me on what ITIL can or can not do. I do know what ITIL can do and what it cant.
Cordially yours; _________________ John Hardesty
ITSM Manager's Certificate (Red Badge)
Change Management is POWER & CONTROL. /....evil laughter
Joined: Jan 23, 2006 Posts: 13 Location: San Francisco, CA
Posted: Tue Oct 17, 2006 3:05 am Post subject: FSC vs. FSR
Thanks for all the information. I want to make sure I understand what has been said...
So from a change management prospective you use the FSC to view all the individual changes that will be implemented into the IT operational environment.
From a release management prospective you use a FSR to view all the changes with regard to release, how they are packaged and all the details associated with the release. I am currently writing the policies and procedures for release management and I want to ensure that I am addressing the proper schedule. Can someone give me a real life example of how the forward scheudle of release is implemented?
I just want to add a quicky. An FSC does not need to be communicated as is to all in the organization.
First of all, there are changes that are sensitive in nature. Here's a fun change "Special backup and freeze of 5000 user accounts this Friday".
Also, communication of the FSC is to keep people informed of the changes that can impact their environments, so they can be prepared. Ideally, a web interface on an intranet would provide only the records that could affect the current user. When your IT department has over 1000 employees, you may be running so many changes that you would simply overload people with information.
Finally, there probably is a number of changes that you may not want to communicate because they may highligh security risks: release of a security patch etc.
So, open communication is good, ... at the right level, with the right people, at the right time... _________________ BR,
Fabien Papleux
Accenture
Technology Consulting | Service Excellence
Red Badge Certified
You cannot post new topics in this forum You cannot reply to topics in this forum You cannot edit your posts in this forum You cannot delete your posts in this forum You cannot vote in polls in this forum
Forum FAQ
Search
Usergroups
Profile
Log in to check your private messages
Log in
