CORPORATE SYSTEMS CHANGE REQUEST (CR)

INFORMATION TO BE PROVIDED BY CONFIGURATION MANAGEMENT OFFICER
1. CR #: / 2. Date Request Logged: / 3. CCB Review Date:
4. CR Status: ____ Open ____ Closed / 5. Date Status was revised:
INFORMATION TO BE PROVIDED BY ORIGINATOR
6. Name / 7. Phone No.: / 8. Organization: / 9. Date Created:
10. Associated
CR # /Trouble Ticket#: / 11. Category:
____ System Mod
____ Data Fix
____ Deviation
____ Waiver / 12. Priority
____ Routine
____ Urgent
____ Mandated
____ EMERGENCY / 13. Severity:
____ Low
____ Medium
____ High
____ Critical / 14. Change Type:
____ System Setup
____ COTS
____ Hardware
____ OS
____ Software
____ Document
15. System: / 16. Requested Implementation Date:
17. Title:
18. Description of Proposed Change:
19. Benefit and/or Justification: (Detailed Cost Savings, # of Transactions Saved, # of FTEs Saved, Cycle Time Reduction, Legislation or Legal Reference for Mandated Changes):
20. Impact if Not Approved:
INFORMATION TO BE PROVIDED BY THE TECHNICAL LEAD/DEVELOPMENT MANAGER
21. Technical Lead / Development Manager: / 22. Date: / 23. Phone No.:
24. Person Assigned: / 25. Requirements Analyst: / 26. System Version/Release:
27. Impact Statement (Note any/all system downtime):
28. Level of Effort/Time Estimate: / 29. Projected Start Date: / 30. Projected End Date:
31. Configurable Items (CIs) Affected:
ENGINEERING REVIEW BOARD (ERB) RECOMMENDATION (Optional)
32. Disposition: ____Approved ____Conditionally Approved ____Disapproved ____Withdrawn _____ Deferred
33. ERB or Technical Comments:
34. Authorizing Signatures
Date:
Date:
CONFIGURATION CONTROL BOARD (CCB) RECOMMENDATION
35. Disposition:____Approved____Conditionally Approved____Disapproved ____Deferred____ Withdrawn
36. Target Release: / 37. Release/Implementation Date: / 38. Approved Priority:
____Routine ____ Urgent ____Mandated ____EMERGENCY
39. Comments:
40. Authorizing Signature(s)
Date: / Date:
Date: / Date:

1.Instructions

A.Basic Form Instructions

If additional space is needed, it is appropriate to enter “See Attachment” and attach additional pages.

Blocks 1-5 are completed by the Configuration Management Officer ONLY.

  1. CR#: Enter the unique identification number for each Change Request (CR). The Configuration Management Staff maintains the CR log.
  2. Date Request Logged: Enter the date the CR was logged into the CR database. The Date Request Logged is NOT the creation or origination date.
  3. CCB Review Date: Enter the target date of the CCB meeting at which the CR will be addressed.
  4. CR Status: Enter a status of “Open” when the CR is logged into the CR log. The CR remains open until all actions required by the Change Management plan are completed.
  5. Date Status was revised: Enters the date on which the CR was opened and changes the date when the CR is closed. Dates of disposition (CCB or ERB) are recorded in the comments or signature blocks at the bottom of the form.

Blocks 6-20 are initiated by Originator. Subsequent reviewers of the CR should add additional information as needed.

  1. Name: Enter the full name of the Originator.
  2. Phone Number: Enter the telephone number (including area code) of the Originator.
  3. Organization: Enter the Agency or ACFO division of the originator (NOT the Agency affected by the CR).
  4. Date Created: Enter the creation date of the CR.
  5. Associated CR#/Trouble Ticket#: Enter the number of an associated CR or Trouble Ticket; otherwise enter “n/a.”
  6. Category: Enter an “X” in the appropriate blank.
  7. System Mod – System modifications include all changes that affect system functionality, operation, or structure.
  8. Data Fix – Data Fixes are changes modifying the business rules within the system that do not affect how the system operates and do not adversely affect other instances or systems.
  9. Deviation – A request to permit a noticeable deviation from the established process or standard.
  10. Waiver – A request to permit a one-time delivery of a product or service that does not meet documented standards.

Blocks 12-13 provide the ERB and the CCB with an indication of the CR’s level of importance.

  1. Priority: Enter an “X” on the appropriate blank to indicate the originator’s urgency of CR implementation.
  2. Routine – Indicates that the change can be implemented when resources are available or with the next feasible release.
  3. Urgent – Indicates that the problem can be tolerated for a short time, but should be corrected as soon as possible to prevent loss of system capability or user job-performance. If a system shutdown is immediately imminent or users suddenly lose a needed capability, the problem becomes an EMERGENCY.
  4. Mandated – Indicates that the change addresses a legal or legislative modification directed by or proposed to comply with required orders, directives, or instructions. (See Detailed Instructions).
  5. EMERGENCY – Indicates that the change is needed to immediately correct an error that has caused or will cause a complete or severe loss of a high priority capability or system functionality, and no workaround is available. An EMERGENCY CR Priority does not automatically indicate that a problem is critical. A critical situation does not necessarily imply that emergency handling is required.
  1. Severity: Enter an “X” on the appropriate blank to indicate the degree of impact of the problem or enhancement on the system or system’s utility.
  2. Low – Identifies an error that causes no serious operational problem or identifies a system enhancement that would improve system functionality or performance. An Error that has only cosmetic or other insignificant effects on the continued production use of the system, such as formatting or spelling errors.
  3. Medium – Identifies an error that has caused or will cause problems in operations or loss of server usability. A workaround or alternative is available and the problem can be tolerated for a short time, but a permanent solution should be implemented. Identifies an enhancement that would significantly improve system functionality or performance. An Error that has more than a cosmetic or insignificant effect on the continued production use of the system.
  4. High – Indicates an error that has caused or will cause a loss of service or loss of server usability to a large number of users or a mission-critical system. Indicates an enhancement that would greatly prevent such losses or provide a major performance increase. An Error that severely impairs production use of the entire system or important system processes, but which does not prevent operationally critical processing. Production use of the system is possible, but only with temporary work-arounds.
  5. Critical – Indicates a problem that has caused or will cause a system crash or cause the complete loss of system capabilities. An Error that prevents operation of the entire system or operationally critical system processes, or which destroys important non-recoverable data, and for which no temporary work-around is known and available.
  1. Change Type: Enter an “X” on the appropriate blank.
  2. System Setup – Indicates the CR addresses the standard configuration of a unit or set of similar units (e.g., a standard user desktop configuration, arrangement of instances and partitions, standard server setup).
  3. Commercial Off the Shelf (COTS) – Indicates the CR addresses software of which the development is not under the direct control of the CCB Chair (i.e. provided by a vendor or outside agency).
  4. Hardware – Indicates the CR addresses a hardware component of the system. The CR may address the connectivity of the components.
  5. Operation System (OS) – Indicates the CR addresses the computer operating system (e.g., AIX, LINUX, OS390, Windows, etc).
  6. Software – Indicates the CR addresses software of which the development is under the direct control of the CCB Chair. The CR may apply directly to the software or to the software package including a combination of source code, documentation, and manuals.
  7. Document – Indicates the CR addresses a specific document.
  1. System: Enter the name or acronym for the system primarily addressed by the CR (e.g., IAS, PCMS, CPAIS). Use the organization name/acronym (e.g., FFIS, FNS, PSD) only if an organization asset other than directly system related is addressed.
  2. Requested Implementation Date: Enter the requested implementation date of the change.
  3. Title: Enter a brief phrase or statement (less than one line if possible) that indicates the specific subject of the change. Make the title unique to prevent confusion between CRs. The Title may be changed by the CM Team or higher authority, if necessary.

Blocks 18-20 are used to provide decision makers with sufficient information to analyze the proposed change and to arrive at an informed decision. If the originator is a user, this block may indicate what the result of the change. The Technical Lead/Development Manager will provide the required technology details.

  1. Description of Proposed Change: Provide a detailed description of the proposed change and associated system impacts. If additional space is needed, enter “See attachment” and provide the description on pages following the form.
  2. Benefit and/or Justification: Provide the advantages to be gained in terms of system/user capability: performance if the change is approved; which authority has mandated the change (mandate); or how the change will solve the current problem.

The following are example questions that should be answered and populated in the CR form.

What costs are saved by this change?

What number of system transactions is saved by this change?

What number of Full Time Equivalents (FTEs) is saved by this change?

What is the decrease in cycle time provided by implementing this change?

What is the legislation requiring this mandated change?

What is the law requiring this mandated change?

  1. Impact if Not Approved: Provide the negative impact on the system or on the users if the change is not approved. As applicable, describe the current state of system and what the likely end result will be if the change is not approved.

The following are two examples of how Blocks 17-20 should be populated in order for the ERB and CCB to make proper approval CR decisions.

17.Title: FFIS-MINC interface should select correct VEND name and address based on 1099 Name/Address on VEND.
18. Description of Proposed Change: The weekly FFIS-MINC selection process should apply name/address based on the 1099 Name/Address flag on VEND.
19. Benefit and/or Justification (Detailed Cost Savings, # of Transactions Saved, # of FTEs Saved, Cycle Time Reduction, Legislation or Legal Reference for Mandated Changes): The following benefits are achieved by this CR: reduction in the number of taxpayer privacy issues with regards to information being sent incorrectly, reduction in the number of erroneous entries in the IRS unmatched TIN/Name file; therefore a reduction in the cost of unnecessary analysis and action, reduction in the number of inquires and return mail analysis.
20. Impact if Not Approved: The following impacts are present if this CR is not approved: increase in the number of taxpayer privacy issues with regards to information being sent incorrectly, increase in the number of erroneous entries in the IRS unmatched TIN/Name file; therefore an increase in the cost of unnecessary analysis and action, increase in the number of inquires and return mail analysis.
17. Title: Add MCC to all purchase card output for 1099 reporting CDs – matched and unmatched. Add MCC to the file sent to MINC.
18. Description of Proposed Change: Add MCC to each PCMS purchase card transaction for 1099 reporting (including CDs). Both the matched and unmatched output should reflect the MCC for purchase card transactions. Add MCC to the file sent to MINC so it can be included in the reference field on the MINC record.
19. Benefit and/or Justification (detailed cost savings, # of transactions saved, # of FTEs saved, cycle time reduction, legislation or legal reference for mandated changes): MCC are identified by IRS regulations as either 1099 reportable or not. Requirements are being developed to cross walk reportable BOCs to reportable MCCs. The MCC on the reports will assist with research and analysis when inquires are received from Agencies or vendor regarding a PCMS purchase card transaction. This CR eliminates the need to download the VISA file to obtain this information. Adding MCC to the PCMS-MINC file will allow the MCC to be part of the MINC reference field and assist responding to 1099 inquires.
20. Impact if Not Approved: The current functionality requires the manual download of VISA files and delays the response to taxpayer inquires regarding 1099 reporting issues. If this information is not added to the PCMS-MINC file, then extra manual steps will remain to obtain the necessary information.

Blocks 21-31 are completed by Technical Lead/Development Manager; after completion, forward to the Configuration Management Staff.

  1. Technical Lead/Development Manager: Enter the name of the Technical Lead/Development Manager. The Technical Lead/Development Manager will be the primary point of contact for all technical questions regarding the CR.
  2. Date: Enter the date the Technical Lead/Development Manager completes this section of the CR.
  3. Phone Number: Enter the phone number of the Technical Lead/Development Manager.
  4. Person Assigned: Enter the name of the person who is responsible for the development of this CR.
  5. Requirements Analyst: Enter the name of a person who will complete the requirements analysis and document the requirements if the CR is approved.

NOTE: The Technical Lead/Development Manager, the Person Assigned, and the Requirements Analyst may be the same person or different people, but each role must be assigned.

  1. System Version/Release: Enter the recommended system version/release number of the affected system. Depending upon the priority of the change, this may be the current release or a forthcoming release. If the affected item is not part of the existing system or release, enter “N/A.” The ERB/CCB will determine the required version/release in Block 36.
  2. Impact Statement: Enter a detailed account of all operational impacts to the system when the change is installed and implemented, including such information as expected system downtimes (complete or partial), maintenance windows, expected temporary loss of capabilities, system slowdowns, etc.
  3. Level of Effort/Time Estimate: Enter estimates of resources, time, and materials required to complete the change.
  4. Projected Start Date: Enter the estimated/recommended date for beginning work on the change.
  5. Projected End Date: Enter the estimated/recommended date by which this change can be completed and implemented.
  6. Configurable Items (CIs) Affected: List all configurable items affected by the requested change. (See Detailed Instructions.)

Blocks 32-34 are completed by the ERB.

  1. Disposition: Enter an “X” in the appropriate blank. This will be stated in Block 33. If other than “Approved”, state the reason in Block 33.
  2. ERB or Technical Comments: Enter comments in this field as necessary. State the reason for any dispositions other than “Approved.” All comments become a permanent part of the CR record. (See Detailed Instructions).
  3. Authorizing Signature: Enter the name and date of the ERB Chair.

Blocks 35-40 are completed by the CCB.

  1. Disposition: Enter an “X” in the appropriate blank. If other than “Approved,” state the reason in Block 39.
  2. Target Release: Enter the system version/release in which this change should be implemented.
  3. Release/Implementation Date: If the change is to be implemented in a future release, enter the scheduled date of that release. If change is for “immediate” implementation, enter the date by which implementation is to be completed.
  4. Approved Priority: Enter an “X” in the appropriate blank. The CCB will determine and approve the priority of the change.
  5. Comments: Enter comments in this field as necessary. State the reason for any dispositions other than “Approved.” All comments become a permanent part of the CR record. (See Detailed Instructions).
  6. Authorizing Signatures: Enter the names and dates of the CCB members certifying the decision.

B. Detailed Form Instructions

Block #Notes

11.bUnless otherwise directed by the CCB Chair, CPAIS data fixes do not follow the normal Change Management processes in that they require review and approval only by the CCB Chair (For example: Establishing user accounts on the system.)

12.cA “Mandated” CR will follow the Change Management processes as any other CR, but the ERB or the CCB may direct more expeditious handling if necessary to meet a mandated completion date.

25Information from this analysis may be used to update Blocks 18, 19, and 26-31.

31The implementation of a CR in one part of a system may have a rippling affect on the baselines of several other systems or items. In order to adequately maintain the baselines, all affected items must be identified and addressed. For example, in complex systems, a request to modify a form on users’ desktops may require a change to the form, the software that creates it, the software that handles the data, the user manual, the training program, an interface with another system).

33The ERB Chair will provide the information and the Configuration Management Staff will update the comments sections as necessary to provide a complete history of ERB actions and dispositions.

The format should be:

“Date (MM/DD/YY) – note(s)). For example: 07/07/06 – Deferred until next meeting to obtain cost data.

39See “33” above.

Revised Form AD1168 (03/06/07)