why on earth did ITIL V3 rename Forward Schedule of Change to Change Schedule?

This has been bugging me for a long time: why on earth did ITIL V3 rename Forward Schedule of Change to Change Schedule? Beats me, and it is counter-productive.

FSC is one of the most widely used ITIL terms in the IT industry. Change is one of the most widely adopted of ITIL processes. Every week in hundreds of thousands of companies worldwide they publish the FSC.

One of the greatest benefits of ITIL is standardisation of language. What are all those sites expected to do? Change all their reports and their documentation to comply with the whims of ITIL? For what benefit? ITIL is supposed to record what the industry does, not mess around with it. ISO20000 (-1 9.2) doesn't care. COBIT (4.1 AI6) doesn't care. MOF (5.2 Key terms) calls it Forward Schedule of Change and we're all friends with MOF now. So it wasn't a compliance thing.

As many folk aready know thanks to Marc Buzina's entry in BOKKED, the Service Transition book itself gets confused and keeps referring to "SC" not "CS".

I'm betting that at this point 90% of all existing schedules of change are called FSC not CS. I think ITIL V3 Edition 2 (to be known on this blog as the ITIL Refresh Refresh) should change it back before we end up with two terms in general usage.


FCS vs Change Schedule

The importance of a widely distributed list of changes that includes those scheduled for the distant future, planned in the short term, and those that have recently been made cannot be understated.

What such a list is called is less important than the list itself being comprehensive, easy to access by anybody, easy to understand and relatively easy for anybody to establish the impact to themselves and their services.

What it should be called and what it is called, are two different matters, though. A poll that finds that most people call it 'fred' doesn't mean that 'fred' is the best name for it - or even if the name itself matters much.

I think that 'Change Schedule' or 'Change list' are better than 'Forward Schedule of Changes', simply because they are simpler. They also have the virtue, as has been pointed out, of apparently not meaning only changes to be made, leaving out changes that have recently been made.

I've no objection to FSC, it is, as you say, a commonly understood term in circles where this sort of thing is discussed regularly.

The advantage of replacing it with 'Change Schedule' or 'Change List', apart from clarity, is that the fad of talking about 'going forward', when you mean 'in future' is likely to be short-lived. It's the sort of jargon that catches on for a while, in the geek community, as an exclusive term - people who don't grok it, or use the standard English term, are not hip, or groovy, they're squares. Once such terms become ubiquitous so that even the dimmest manager talks about having Monday meetings 'going forward' and your waitress asks if you'd like anything more 'going forward', you know that it has lost its exclusivity and it's time to invent a new jargon word to confuse everybody.

'Going forward' is now a painful term used by anybody who hopes to use form and style rather than substance; it's the mark of the chap who is always just that little bit late for the trend. So removing the term 'Forward' from the schedule of changes shows that it is a real and important thing, not just a management fad for geek managers who are just that little bit behind the times. After all, what is more pathetic than being just a little behind the times? Being a decade, or more, out of date shows an independence, a reluctance to indulge in fads, possibly, even, it reflects more experience in the field than the callow youths, just out of Uni, who have to grasp for 'happening' terms they hope will make them seem a little bit older, as they'd grow a straggly moustache.

FSC is well established

FSC is well established, at least from ITIL V2 in 2001.

For any change the potential advantages should outweigh the cost and impact.

A schedule of change is 90% forward and 10% retrospective "recently been made" (more CFs for you Brad!) and the major interest is in what is coming up. I don't think the name is terribly misleading just a little imprecise.

It is widely used. ITIL V2 set it as the "standard" eight years ago. MOF agrees. COBIT and ISO20000 have no opinion. Why change other than to annoy Microsoft (good) and thousands of Change Managers (bad)?

My point entirely - ITIL V2 renamed it to begin with...

My point entirely (earlier).

ITIL v2 renamed something in common use, and easier to say - to something else - perhaps so they could lay claim to another unique concept within ITIL. Can we please get back to plain English. As for 'Forward' - wonder how that translates - I was sometimes criticized by my mum for occasionally being a bit too 'forward' - better than 'backward' I suppose.

Anyway, a change schedule needs to reflect the chronological timeline of all changes and support the need for example to look back, perhaps to investigate an issue, and look forward to assess risk and allocate resources. If folks insist on sticking with the forward change schedule term thats there choice - but perhaps one day should we ever get a vote - I vote for a 'backward change schedule', and a 'right now change schedule'.

summary notification to helpdesk and ops

It's not often i disagree with you Ian but I do here.

A FSC is a summary notification to helpdesk and ops and others of what to be ready for - a heads-up; a mapping to ensure changes don't clash; and a way to group changes into windows. The record of changes that have just happened and have happened in the past are in the Change database where they belong. they can be reported if desired but that isn't a schedule and the timeline aspect isn't terribly interesting any more.

Is the FSC nothging but a query?

Perhaps we are getting past ourselves here. The FSC could be regarded as the result of a query to the change database.... show all future changes of this status to this location or service, within this period. As could the past change schedule, and any that are over the immediate horizon.

Would it help if we regarded the FSC as one type of query against the change system data?

Disagreement encourages debate and learning

Sokay. I was expressing things from my experience. A change schedule needs to reflect recent history - perhaps the past 72 hrs - to traverse holidays and weekends. A Service support team may need to look back on a Monday morning to review recent changes and when they happened against the work schedule to troubleshooot. We ran a rolling timeline at one bank - 72 behind - 48 ahead.... the database also stored distant future changes.....

As for when a past change becomes uninteresting or irrelevant - I suppose after the post implementation review indicates they are 'successful' - then I would archive them to a database... which i sactually the same thing as a schedule - its just a different query... oops loop detected...

Change Schedule is easier to

Change Schedule is easier to understand..FSC was hard to establish, often missleading and only accepted according to the introduction of the formerly new ITIL V2 stuff. If we have to review Changes, ITIL and whatever..why not using obvious terms?

Annoying Change Managers is a bad thing?

As you can see in the other thread, essential as Change Managers are, they're not always every techie's friend. This is, I think, because the ITIL notion of a 'Standard Change' [which includes proper communication and approval] is not properly deployed. It's in the techie's interest to submit and test a standard change so that he doesn't have the hassle of updating the configuration or remembering who to tell or the risk of being blamed for catastrophes.

There's another, serendipitous, benefit, revealed in this thread. Changing the name gives another reason to publicise the process, to discuss what the list means and why it is important. Any raising of awareness is a good thing.

In my experience, too, any Change Manager, worth his salt, is made of sterner stuff than to be annoyed by something so minor.

I can see Chokey jumping

Skep is Chokey itching at this article;

"FSC is one of the most widely used ITIL terms in the IT industry. Change is one of the most widely adopted of ITIL processes. Every week in hundreds of thousands of companies worldwide they publish the FSC."

"I'm betting that at this point 90% of all existing schedules of change are called FSC not CS."


The IT Skeptic's Crap Factoid

OK Brad, you win. I plead guilty to having promulgated a CF. The proportion of schedules of change called a FSC is not 90% at all, it is - according to rigorous scientific research based on best IT practice - about 60%. Schedules named FSC only outnumber schedules named CS by 2 to 1. One can only conjecture however on what the proportion would be if V3 had not changed the name three years ago.

Hold on a minute....

Hang on a minute... what about pre-ITIL and the non-ITIL audiences?

I recall our schedules being named 'Change Schedules' up to ITIL's rename of that to the 'FSC'. Also - there are a lot of service (provider) organizations out there that are non-IT and yet to discover ITIL in any shape or form (and it seems your website). What do they call the schedule of changes? I named it the 'Change Schedule' in the USMBOK because of the preponderance of non-ITIL, non-IT references using that term...

And less we forget - this has absolutely nothing to do with the schedule of authorized changes to the product plan (service plan) - the 'Service Revision Plan', the Maintenance Schedule (as used by Facilities Management and those maintaining the infrastructure), and Release Schedule - the 'forward' plan of when releases are engaged..... the transportation timetable....


I only saw 44% for FSC..

Brad Vaughan

of those who HAVE

59% of those who HAVE a schedule call it a FSC. actually 57% now (CS 31%). Our survey is more accurate of course but I've rounded up to the nearest 1% for convenience


LOL Brad, there's a difference between a rhetorical "90%" and "I'm betting...", and a Crap Factoid presented as serious research, but anyway let's have a poll :)

Change engine needs a forward and reverse

The name 'forward change schedule' was inappropriate given any change calendar or schedule must offer a recent view of the past to assist troubleshooting. How many of us recall the infamous network down situation on a Monday...? The change schedule works fine for me and always was a better term. What we need is more guidance from ITIL on what a schedule contains and advice on how far back and forward to view changes....

Syndicate content