By ITIL® from Experience©Projects sometimes disagree that they have to log Request For Changes (RFC). It is believed that since the project was approved, no other authorizations are required to execute their plan. After all, they are governed differently than operations with a different change management process (e.g. Change Requests to scope, time, resources are reviewed by a Change Control Board1). In addition, their go-live date is usually determined by the project plan independently of operational constraints or consideration to the Change Schedule
(ITIL® Service Transition) A document that lists all authorized changes and their planned implementation dates, as well as the estimated dates of longer-term changes. A change schedule is sometimes called a forward schedule of change, even though it also contains information about changes that have already been implemented.
Source: ITIL® glossary and abbreviations, English, 2011 www.itil-officialsite.com/InternationalActivities/TranslatedGlossaries.aspx
The fact of the matter is that if they want to implement something in operations, they have to comply with the operations framework, processes and governance. These are the laws of the land, sort of speak and they must comply with them; “when in Rome do as the Romans.” Operations is similar to an airport. If a plane wants to land at a certain airport, it needs to get itself on their radar, comply with the schedule and runway it is given. Failure to obey would result in chaos, confusion with potentially dire results.
Projects need to log RFCs for the following reasons:
- Enables the detection of potential conflicts between changes
- Ensures that it is scheduled for an authorized release window
- Provides a mechanism to:
- Change the status of Configuration Items (CIs) in the Configuration Management Database (CMDB) (e.g. Dev/Test to Production/Live)
- Maintain the relationships between CIs in the CMDB
- Ensures that Configuration Items comply with the IT asset and architectural standards of the organization (e.g. Hardware, Software)
- Ensures that security and IT service continuity (I.e. Business Continuity Management or BCM) requirements are met
- Confirms that the support organization and the Service Desk are aware of their new responsibility and have the information required to perform their role
- Confirms that Customers and Users are aware of the release
- Enables operations to quickly identify the cause of incidents caused by a change
- Provides the input to other ITIL processes and to the Change Management process.
For all these reasons, projects must log RFCs before releasing any component of their solution. As an added benefit the organization will have a detailed configuration of the system in the CMDB once the project is complete as it was documented in RFCs along the way. Nonetheless, a project is like a big Service Request and should be treated with the same approach and rules. Thus, several RFCs might be required to complete the project.
- Is a reboot a change
- What is a change
- Should project activities be logged and tracked in the ITSM Tool
- Should projects log Incidents and Problems
Copyright 2012-2014 - ITIL® from Experience - D.Matte