The Forward Schedule of Change

What is a Forward Schedule of Change? In short, it’s a document that lists Changes and their planned implementation dates.

Interestingly, the term “Forward Schedule of Change” hasn’t been used officially in ITIL since v2. For ITIL v3 it was updated (in name only) to “Change Schedule”, and that terminology has remained in ITIL 4. Despite that, my experience is that the vast majority of folks have continued to refer to the idea as the “Forward Schedule of Change”, or “FSC”, and I’m going to do the same thing.

There are a lot of different approaches to an FSC. Some FSCs list only approved Changes, but an FSC can included “planned but not confirmed” deployments, planned project releases, or even be aligned to non-Change information as well – perhaps showing patterns of business throughout the year or major events in the organisational calendar. In many cases the FSC is most usefully presented as a calendar of events, rather than a strict list of changes – ultimately the FSC is a tool to support process and services, rather than an outcome in itself.

As with many elements of Change Management, curation is at the heart of the FSC; all the information in the FSC already exists somewhere within the organisation, but two key things that an FSC provides are centralisation, and visibility.

Centralisation so that we can see the potential for conflict between different changes, and identify change-heavy periods, by reference to a single source of information.

Visibility because that information isn’t only useful for the Change Manager. While the FSC may not be public, there is usually a surprisingly wide range of stakeholders who can benefit from sight of it:

Service Owners and Managers who may be planning their own deployments, can use an FSC to rule out contentious dates well before raising to CAB.
Service Desk Managers can use it to plan for potential spikes in call logging, for changes with unavoidable user impact (or risk of same).
User communities often value information about when services they rely on will be at risk, or unavailable.
An FSC can also be useful to see whether there are any changes going on right now, which can be a useful diagnostic check in case of unexpected changes in service availability.

If you’re reading this from within The University of Edinburgh, you may be familiar with our IS Alerts system, and if so you’ll probably recognise some of these functions with at least passing familiarity. To be clear, the IS Alerts system isn’t a Forward Schedule of Change, but it certainly is the tool that has been fulfilling some of those needs for us. And in terms of communicating planned work to end users, it’s likely to continue in that role for a while yet.

However, in recent months the Go CAB have been using an Experimental FSC hosted on our Wiki, which pulls information (semi) automatically from a number of sources, and displays them in Calendar format. This supports the established practice at CAB of looking for conflicts between planned changes.

The data sources for this FSC are Change Management, Project Management, and also the core University Calendar. We’ve also made some strides collecting key dates from different business areas, and incorporating those into the main calendar.

Deploying the right calendar tool has been a real challenge – perhaps for another blog post. Despite all the strong theory around FSCs, affordable off the shelf solutions seem to be in scant supply – or at least, failing to make themselves known.

That said, despite some maturity gaps related to age, tools like the IS Alerts system remains rare in my experience as well – which is interesting, considering some of its goals are reasonably close to a classic FSC.

While ultimately we should be agnostic about the presentation tool, in practice this seems to be an area not well served in general.