5.2 Change Management Design Pattern - Veterans Affairs
VA Enterprise Design Patterns:4. IT Service Management4.2 Change ManagementOffice of Technology Strategies (TS)Architecture, Strategy, and Design (ASD)Office of Information and Technology (OI&T)Version 1.0Date Issued: November 6, 2015
THIS PAGE INTENTIONALLY LEFT BLANK FOR PRINTING PURPOSES
REVISION HISTORYVersionDateOrganization0.1ASD TS0.5ASD TS0.7ASD TS1.0ASD TSNotesInitial DraftSecond draft document with updates made throughoutdocument based upon initial internal/externalstakeholder review and comment.Third and final draft for stakeholder review prior to TSleadership approval/signature. Updates made followingPublic Forum collaborative feedback and workingsession.Final version for TS leadership approval and signature,including all applicable updates addressing stakeholderfeedback and Section 508 Compliance.REVISION HISTORY ine Meadows-Stokes9/2/2015RoleJacqueline Meadows-StokesASD TS – Management and Program AnalystASD TS – Management and Program AnalystJacqueline Meadows-StokesTim McGrailPaul A. Tibbits, M.D.ASD TS – Management and Program AnalystASD TS – Senior Program AnalystASD – Deputy CIO
TABLE OF CONTENTSContents1.0 INTRODUCTION . 11.1 BUSINESS NEED.11.2 APPROACH .12.0 CURRENT CAPABILITIES AND LIMITATIONS . 22.1 THE CURRENT STATE OF CHANGE MANAGEMENT (CM) .23.0 FUTURE CAPABILITIES . 33.1 ALIGNMENT TO THE TECHNICAL REFERENCE MODEL (TRM) .84.0 USE CASES . 9APPENDIX A. DOCUMENT SCOPE . 10SCOPE .10DOCUMENT DEVELOPMENT AND MAINTENANCE .11APPENDIX B. DEFINITIONS . 12APPENDIX C. ACRONYMS . 16APPENDIX D. REFERENCES, STANDARDS, AND POLICIES . 18
FIGURESFigure 1: Current State of Change Management . 3Figure 2: Enterprise Change Management aligned with a Federated CMDB . 5Figure 3: Notional Enterprise Change Management Process . 6Figure 4: Change Management Use Case . 10Figure 5: Change Management Use Case . 10TABLESTable 1: Representative VA Tool Categories and Approved Technologies . 9
1.0 INTRODUCTIONThe Office of the Inspector General (OIG), Federal Information Security Management Act (FISMA) andFederal, Identify, Credential, and Access Management (FICAM) audits reported a material weakness inchange management controls. VA has not fully implemented procedures to enforce enterprise standardsystem development and change management controls for mission-critical systems. Software changesto mission-critical systems and infrastructure network devices do not follow standard software changecontrol procedures. The OIG audit discovered numerous test plans, test results, and approvals eitherincomplete or missing. Lines of business have invested in several tools for asset discovery, datanormalization, and configuration management that do not align with an enterprise change controlpolicy.1.1 Business NeedEnterprise change management ensures compliance with governance, legal, contractual, and regulatoryrequirements. By not enforcing a standardized change control methodology, system developmentprojects may be inconsistently developed, tested, and migrated into production. This places VA systemsat risk of unauthorized or unintended software modifications.Service and infrastructure changes can be managed more effectively through enterprise change controlsthat will: Reduce failed changes and associated service disruptionDecrease unauthorized changesMinimize unplanned outagesLower the number of emergency changesReduce delayed project implementations1.2 ApproachChange management is a control process responsible for ensuring that changes are business-aligned anddo not pose undue risk. This Enterprise Design Pattern describes the process for establishing enterprisechange management and defines the factors that are critical to its success.The purpose of this document is to provide guidance on applying best practices to plan, implement,monitor, and improve enterprise change management. Process initiatives and service implementationefforts should align with the proposed framework. Supporting this purpose, the document will: Define best practices to drive the implementation of Enterprise Change ManagementDefine the change control framework required to meet compliance with approved standardsRecommend a set of milestones for implementationPage 1
2.0 CURRENT CAPABILITIES AND LIMITATIONS2.1 The Current State of Change Management (CM) Absence of Enterprise CM Office: An Enterprise Level Program Office that oversees the VAChange and Configuration Management processes and ensures compliance needs to beestablished. While enterprise policy and OIT operational change management processes exist,they are not enforced consistently across the enterprise. Multiple change management systems and tools: Multiple change and configurationmanagement tools are dispersed throughout the enterprise. These tools are not fully utilized,lack interoperability, and collect change information at varying levels.o Region four (4) uses Serena Toolo Enterprise Security System (ESS) uses Change Gearo Enterprise Systems Engineering (ESE) uses both CA and BMC Remedyo Office of Information Security (OIS) uses Government off the Shelf (GOTS) Producto Region three (3) uses CA and GOTS Producto Region two (2) uses CA tool not aligned to the current VA Data CentersLimitations of current change systems: Existing systems operate in silos. Change releases areimplemented with no oversight. Separate processes exist for scheduling and release with littleto no coordination on enterprise impact. Page 2
Figure 1: Current State of Change ManagementAs shown by Figure 1, changes are fed into the discovery tools but these changes are not reported to theConfiguration Management Database (CMDB) to update the baseline of the affected ConfigurationItems (CI). These challenges and limitations present a loosely coupled infrastructure that: Provides a weakened defense against unauthorized changeNon-compliance with baseline standardsIncreased security vulnerabilities such as malware, back-door attacks, and other harmfulsecurity threats due to non-standardized and enforced configuration control3.0 FUTURE CAPABILITIESEnterprise Change Management ensures all changes are assessed, approved, implemented, andreviewed in a controlled manner. As a result, any modification to the IT environment—whether itPage 3
involves an addition, maintenance, or deletion of a service or service component—is in line with theoverall business strategy.The goals of Enterprise Change Management are: Single source of Change Record Information across the enterpriseAutomated and integrated change record logging and trackingSingle approval provided at appropriate change management jurisdiction levelAuthorization(s) provided at the appropriate change management jurisdiction levelsRisk and Impact Assessment activities and Implementation activities documented and linked aspart of the Change RecordChange Status awareness throughout the lifecycleStandard management reusable reportsAll CIs subject to change management require monitoring by an endpoint manager and scanning tool tomaintain multiple standards mapped to the VA core policies, as shown in Figure 2. All data from eachendpoint management and scanning tool is normalized into a standard dataset. This dataset isreconciled against a product catalog repository to validate each CI’s current baseline adheres to theorganization’s policies, procedures, and federal laws. During this process, a relationship and dependencymapping between information system, its Cis, and information system components must be visible toexamine the IT infrastructure of the VA network.The standard change management process requires a change control process to track all changes from aRequest for Change (RFC) aligned to a RACI matrix. This tracking requires a fully automated hybridservice desk manager tool.A fully automated hybrid service desk manager tool connected to a federated CMDB will support changetracking. The CMDB requirements are as follows: Reflect all changes made to the CI from the time the CI entered the enterprise until itsretirementFilter history for any category the administrator requires including priority, date created, andnumber of requests for changes (RFCs) by CIThe ITSM tools require a Process Flow Status Model that aligns to all change management processstages with mandatory fields assigned for compliance with the organization’s auditing rules. The processflow model must indicate the status of the RFC and send triggers to each stakeholder outlined in theRACI matrix.Page 4
Figure 2: Enterprise Change Management aligned with a Federated CMDBPage 5
Change ManagerChange ControlBoard (CCBs)Figure 3: Notional Enterprise Change Management ProcessPage 6
Initiate RFC - The goal of Change Management is to facilitate all RFCs through clear procedures,automation, and simple checks and balances. If RFC initiation is not managed properly, thiscould lead to misuse of the Change Management system. Clear policies will define who cancreate RFCs, scope of the RFCs, and the information required describe the requirement.o RFCs focus on improving productivity, a service request, an incident management,problem management or any type of request outlined within the change managementprocess. This request will enable the organization to determine any ramifications of thechanges prior to execution to mitigate a potential impact to the IT environment. RFC’sare categorized as Normal, Standard, and Emergency. Routine or recurring changesconsidered to have minimal or no impact on business service can be considered for anautomated process (depending on the type of RFC).Analyze / Plan Change - A comprehensive risk assessment, impact analysis and change plan willimprove the change management process by providing accurate and reliable information. Thechange coordinator is required to route the RFC to the responsible groups for analysis andcompletion of the activity. This ensures complete visibility into the status of the RFC andidentification of potential bottlenecks. Information for this section can be easily accessible fromthe CMDB. A standardized risk assessment provides technical, security, and business analysis aslisted below:oooA technical assessment provides technical risk analysis about change implementationand schedule conflict. This assessment, in conjunction with ITIL release managementprocess will remediate issues and concerns and provide plans for back-out to restore theoriginal baseline.A security impact analysis assesses the change to information systems and theassociated security ramifications.A business assessment provides the potential impact of changes to the business inaccordance with IT budget and cost with relations to the technical assessment forchange. Approve Change - The Approve Change stage involves the Enterprise Change Control BoardECCB, SMEs, Change Coordinators, Approval Stakeholders, and Change Manager to gainagreement with the recommended revision flowing from the Analyze / Plan Change stage. TheRFC is prioritized depending on the severity of the change (e.g. Normal, Emergency). Build - Approved RFCs are assigned to a developer, programmer, technical writer, or other SMEto create the change. The changes are compiled and packaged with appropriate artifacts anddelivered to testing as a build, modified work product, or configuration change. Testing verifiesthe fix, and the change is staged for production and packaged as a release candidate. ThePage 7
change to the CI creates a new baseline with supporting documentation which is approved bythe Change Control Board (CCB). Schedule / Implement Change - Change implementation is a technical implementation thatfollows the guidelines established in the System Development Life Cycle (SDLC) and ProjectManagement Procedures. Validate - The Change Manager reviews the change, tests and validates in a productionenvironment, and monitors in real-time for any problems or issues after the approval of theimplementation phase. The change request status is set pending additional reviews from thechange manager, possible CCB stakeholders, and the change owners.An effective Enterprise Change Management framework provides the flexibility to address processes,technology, and the human aspect of change. Key steps required to transition to an Enterprise wideChange Management process are:1.2.3.4.Obtaining Executive and other Organizational Leadership/Stakeholder’s sponsorshipEstablishing an Enterprise Change Control Office manage and oversee the CCBIdentifying and leveraging existing procedures, policies, tools, etc.Ensuring new changes/requirements are aligned to the organization’s strategic vision andobjectives5. Identifying and documenting overall risks while specifying mitigation plans to address those risks3.1 Alignment to the Technical Reference Model (TRM)All projects are directed to use the approved tools and technologies located in the VA TechnicalReference Model (TRM) to comply with VA Enterprise Architecture and the guidance provided in thisdocument. Approved tools include:Table 1: Representative VA Tool Categories and Approved TechnologiesTool CategoryDisaster RecoveryExample Approved TechnologiesCA IT Asset Management, IBM EndpointManager, Atrium Discovery andDependency MappingMicrosoft System Center ConfigurationManager (SCCM), BMC ApplicationAutomationTivoli Storage Management, BaculaEnterpriseIT Service DeskCisco Agent Desktop, RemedyAsset ManagementData Center Automation SoftwarePage 8
MonitoringOracle Exadata, StrobeSystem Change and ConfigurationManagementHyena, VMware vSphere CLI (vCLI)4.0 USE CASESThe following use case demonstrates the application of enterprise change management described in theprevious section. Analyzing the impact of a change to IT service CIs represents a common use case forthe change management process. According to the type of RFC, the National or Regional CCB approvesthe change to the specific CI if the impact analysis factor is considered minimal or poses no threat to theIT environment. The impact analysis works in conjunction with related ITIL service transition processes.The following steps represent change impact analysis at a high level:1.2.3.4.5.6.7.8.Submitter packages a change order as an RFCCCB retrieves and logs change orderCCB evaluates CI relationships affected by change order, using the CMDBCCB determines whether change order conflicts with another change order or breaks adependency in the CMDBIf Yes, then CCB rejects the change orderIf No, then CCB approves the change orderCCB logs the decision and informs submitter of status of change order for both Steps 5 and 6CMDB automatically updated to reflect CI changes resulting from change orderThe following figure illustrates this use case:Page 9
Figure 4: Change Management Use CaseThis use case can also include real-time monitoring of the CIs, which in turn triggers changes to the ITinfrastructure. Enterprise-wide ITSM tools support automated change detections, which can bepackaged as an RFC for the CCB review and impact analysis. The CCB may also use ITSM tools to visualizethe calendar of changes to mitigate risks to running critical business functions as changes are made.ITSM tools also support change collision detection, which prevents duplicate changes to CIs impactingthe honoring of Service Level Agreements (SLA) with customers.Appendix A. DOCUMENT SCOPEScopePer the Federal Information System Controls Audit Manual (FISCAM) Audit Material Weaknesses #1(Vulnerability Discovery and Remediation) and #6 (Unauthorized Software Discovery and Remediation,there needs to be an enterprise change management process. This document will ensure all changes toall information technology infrastructure and software CIs are managed and communicated in adisciplined and standardized manner to minimize risk, minimize impact and optimize IT Resources inaccordance to the OI&T Enterprise Change Management Program Policy.Page 10
This document does not change the current change management process Standard OperationProcedure (SOP) that OI&T has established. It adds capabilities to the Product Development (PD) andService Delivery and Engineering (SDE) guidance to develop an Enterprise Change Management Processacross all the pillars of the Veterans Affairs (Veterans Health Administration (VHA), Veterans BenefitsAdministration (VBA), and National Cemetery Administration (NCA)).Document Development and MaintenanceThis document was developed collaboratively with internal stakeholders from across the Departmentand included participation from VA’s Office of Information and Technology (OI&T), ProductDevelopment (PD), Office of Information Security (OIS), Architecture, Strategy and Design (ASD), andService Delivery and Engineering (SDE). Extensive input and participation was also received from VHA,VBA and NCA. In addition, the development effort included engagements with industry experts toreview, provide input, and comment on the proposed pattern. This document contains a revision historyand revision approval logs to track all changes. Updates will be coordinated with the Government leadfor this document, which will also facilitate stakeholder coordination and subsequent re-approvaldepending on the significance of the change.Page 11
Appendix B. DEFINITIONSNameDefinitionApproved ListA list of discrete entities, such as hosts or applications that are known tobe benign and are approved for use within an organization and/orinformation system.Authentication (FIPS 200)Verifying the identity of a user, process, or device, often as a prerequisiteto allowing access to resources in an information system.Baseline ConfigurationA set of specifications for a system, of Configuration Item (CI) within asystem, that has been formally reviewed and agreed on at a given point intime, and which can be changed only through change control procedures.The baseline configuration is used as a basis for future builds, releases,and/or changes.EnterpriseChangeControl BoardA board delivering support to the Change Management team by approvingrequested changes and assisting in the assessment and prioritization of changes.ConfigurationThe possible conditions, parameters, and specifications with which aninformation system or system component can be described of arranged.Configuration BaselineSee “Baseline ConfigurationChange Control BoardA board functioning to formally authorize all changes from the VA'sbaseline infrastructure. It is the systematic process of proposing, justifying,evaluating, validating, disposing of proposed changes, and implementingapproved changes, as well as tracking the many changes affecting aconfiguration item's state. The Change Management team ensures thedocumentation and coordination of recommended engineering changes toconfiguration items.Configuration(CNSSI-4009)Control Process for controlling modifications to hardware, firmware, software anddocumentation to protect the information system against impropermodifications before, during, and after system implementation.ConfigurationBoardControl Establishment of and charter for a group of qualified people withresponsibility for the process of controlling and approving changesthroughout the development and operational lifecycle of products andsystems; may also be referred to as a change control board;Page 12
An identifiable part of a system (e.g., hardware, software, firmware,documentation, or a combination thereof) that is a discrete target ofconfiguration control processes.Configuration ItemA Baseline Configuration is a set of specifications for a system, or CI withina system, that has been formally reviewed and agreed on at a given pointin time, and which can be changed only through change controlprocedures. The baseline configuration is used as a basis for future builds,releases, and/or changes.ConfigurationIdentificationItem Methodology for selecting and naming configuration itemsConfigurationManagementA collection of activities focused on establishing and maintaining theintegrity of products and systems, through control of the processes forinitializing, changing, and monitoring the configurations of those productsand systems throughout the system development and production lifecycle.ConfigurationManagement PlanA comprehensive description of the roles, responsibilities, policies, andprocedures that apply when managing the configuration of products andsystems.Configuration MonitoringProcess for assessing or testing the level of compliance with theestablished baseline configuration and mechanisms for reporting on theconfiguration status of items placed under CM.Enterprise ArchitectureThe description of an enterprise’s entire set of information systems: howthey are configured, how they are integrated, how they interface to theexternal environment at the enterprise’s boundary, how they are operatedto support the enterprise mission, and how they contribute to theenterprise’s overall security posture.False PositiveA result that indicates that a given condition is present when it is not.Information System User Individual or (system) process acting on behalf of an individual, authorized(CNSSI-4009)to access an information system.PatchAn additional piece of code developed to address a problem in an existingpiece of software.RemediationThe act of correcting vulnerability or eliminating a threat. Three possibletypes of remediation are installing a patch, adjusting configurationsettings, and uninstalling a software application.Page 13
Request for Change Normal: All changes follow a standardized change process modelfor the type of change being implemented. This process takes thechange through its entire lifecycle; Registration, Analysis,Approval, Develop/Test/Build, Release Approval, Scheduling,Implementation and Verification. Standard: Is a change to a service or infrastructure for which theapproach is pre-authorized by Change Management that has anaccepted and established procedure to provide a specific changerequirement. Emergency: Reserved for changes intended to repair an error in anIT service that is negatively impacting the business to a highdegree. Changes that introduce immediate and required businessimprovements are handled as normal changes, assessed as havingthe highest urgency.RiskThe probability that a particular threat will exploit a particularvulnerability.SystemA set of IT assets, processes, applications, and related resources that areunder the same direct management and budgetary control; have the samefunction or mission objective; have essentially the same security needs;and reside in the same general operation environment. When not used inthis formal sense, the term is synonymous with the term” host”. Thecontext surrounding this word should make the definition clear or elseshould specify which definition is being used.SystemicAn issue or vulnerability found through scanning or discovery that residesin multiple places throughout the enterprise.System OwnerIndividual with managerial, operational, technical, and often budgetaryresponsibility for all aspects of an information technology system.ThreatAny circumstance or event, deliberate of unintentional, with the potentialfor causing harm to a system.VASIVASI is an authoritative inventory of business-oriented applications andsupporting databases providing a comprehensive repository of basicinformation about VA systems; represents the relationships betweensystems and other VA data stores; and captures new systems.Page 14
VulnerabilityA Weakness in an information system, system security procedures,internal controls, or implementation that could be exploited or triggeredby a threat device.Page 15
Appendix C. ACRONYMSThe following table provides a list of acronyms that are applicable to and used within this EnterpriseDesign Pattern document.AcronymDescriptionADDMAtrium Discovery and Dependency MappingASDArchitecture, Strategy and DesignCACA TechnologiesECCBEnterprise Change Control BoardCA SDMCA Service Desk ManagerCCBChange Control BoardCERTComputer Emergency Readiness TeamCIConfiguration ItemCIOChief Information OfficerCMConfiguration ManagementCMDBConfiguration Management DatabaseCOTSCommercial Off-the-shelfCPECommon Platform EnumerationCVECommon Vulnerabilities and ExposuresDHSDepartment of Homeland SecurityDODDepartment of DefenseEOEnterprise OperationsFEAFederal Enterprise ArchitecturePage 16
AcronymDescriptionFICAMFederal Identity, Credential, and Access ManagementFIPSFederal Information Processing StandardsFISMAFederal Information Security Management ActGOTSGovernment Off-the-shelfIBM EPMIBM Endpoint ManagerISInformation SystemITInformation TechnologyITAMInformation Technology Asset ManagementITILInformation Technology Infrastructure LibraryLOBLine-of-BusinessMACMedia Access ControlNISTNational Institute of Standards and TechnologyNSDNational Service DeskOI&TOffice of Information and TechnologyOIGOffice of the Inspector GeneralOISOffice of Information SecurityOMGOffice of Management and BudgetOVALOpen Vulnerability Assessment LanguagePDProduct DevelopmentSCAPSecurity Content Automation ProtocolSCCMSystem Center Configuration ManagerPage 17
AcronymDescriptionSDEService Delivery EngineeringSIEMSecurity Information and Event ManagementSLAService Level AgreementTRMTechnical Reference ModelUS-CERTUnited Stated Computer Emergency Readiness TeamUSGCBUnited States Government Configuration BaselineVADepartment of Veterans AffairsVASIVeterans Affairs Systems InventoryXMLExtensible Markup LanguageAppendix D. REFERENCES, STANDARDS, AND POLICIESThis Enterprise Design Pattern is aligned to the following VA OI&T references and standardsapplicable to all new applications being developed in the VA, and are aligned to the VA ETA:This Enterprise Design Pattern is aligned to the following VA OI&T references and standardsapplicable to all new applications being developed in the VA, which were gathered andreviewed from:#1IssuingAgencyVA2VA3NISTPolicy, Directive, Purposeor ProcedureVA Directive 6004 Directive establishes VA policy and responsibilities regardingConfiguration, Change, and Release Management Programsfor implementation across VA.VA 6500Directive information security program.HandbookDefining overall security framework for VA.800-128Guide for Security-Focused Configuration Management ofInformation SystemsProvides guidelines for organizations responsible formanaging and administrating the security of federalPage 18
#IssuingAgency4NIST5NIST6OMB7OMB8WhiteHouse9VA10 CongressPolicy, Directive, Purposeor Procedureinformation systems and associated environments ofoperationsSP 800-63-2Special Publication — Creating a Patch and VulnerabilityManagement ProgramDesigned to assist organizations in implementing securitypatch and vulnerability remediation programs.800-53Recommended Security Controls for Federal InformationSystems and OrganizationsOutlines the importance of deploying automatedmechanisms to detect unauthorized components andconfigurations within agency networksMemorandum M- FY2013 Reporting Instructions for the Federal Information14-04Security Management Act and Agency Privacy ManagementProvides guidance for Federal agencies to follow the reportrequirements under FISMA.Memorandum M- Guidance for Preparing and Submitting Security Plans of02-01Actions and MilestonesDefines Management and Reporting Requirements foragency POA&Ms, including deficiency descriptions,remediation actions, required resources, and responsibleparties.FISMA Act ofReauthorizes key sections of the Government Information2002Security Reform ActProvides a comprehensive framework for ensuring effectivesecurity controls over information resources supportingFederal operations and assets.CRISPIntended
The standard change management process requires a change control process to track all changes from a . The ITSM tools require a Process Flow Status Model that aligns to all change management process . This assessment, in conjunction with ITIL release management process will remediate issues and concerns and provide plans for back-out to .
3.4 ITIL Change Management Process 25 3.5 Change Advisory Board 29 3.6 Change Management KPI's 31 CHAPTER 4 - EMPIRICAL ANALYSIS 32 . 4.4.1 Process Goals 40 4.4.2 Change Management Process Flow 40 4.4.3 Nature of Change Requests 49 4.4.4 KPI's for Change Management 50 4.4.5 Change Management Tools 50 4.5 Roles and Responsibilities 53 .
Change management is not a stand-alone process for designing a business solution. Change management is the processes, tools and techniques for managing the people-side of change. Change management is not a process improvement method. Change management is a method for reducing and managing resistance to change
change, manage the change, and sustain the change. While change management focuses on ensuring the support of the people, project management focuses on the work tasks to be executed. Coupled together, proactive change management and project management will lead to the actualization of the benefits of the change initiative.
Understand the human element of change by exploring the the emotional cycle of change. See how Change Management fits into the project lifecycle. Develop the leadership skills required for enacting change. Overcoming resistance to change by identifying the reasons for why people resist change. Explore the change management toolkit by using .
Chapter 8: Leadership and Dealing with Change 225 . The Reality of Change 226 . Leader’s Role in Change Management 227 . Organizational Change 228 . Change Leadership vs. Change Management 232 . Facilitating Change 234 . The Board and Change 238
survey was designed to capture data on the specific change and the organization’s change management practices (Organizational Change Survey), while the other survey focused on individual differences and reactions to the change (Personal Change Survey). The specific change being studied was identified at the beginning of each survey
31 A Practical Approach to Change Management (Kotter's 8-steps and beyond) Martin Davis Make the change Ambitious Name the project appropriately Structured and Coherent Change Program Change Leadership Create a sense of Urgency Ensure the change Resonates with the staff Involve everyone and define how they benefit from the change (to reduce resistance)
Below is a diagrammatic representation of the workflow of the change management process Detailed Change Procedures Normal Changes a) Change initiator initiating request for change (RFC) will create an RFC. Change type is Major. Changes should be entered into the system at least two weeks in advance of the actual change date. If change date is .
