Federal Business Opportunities (FedBizOpps.gov) Change Management Plan (CMP)

GSA OFFICE OF GOVERNMENTWIDE POLICY Federal Business Opportunities (FedBizOpps.gov) Change Management Plan (CMP) Issued on October 18, 2002 by the FedBizOpps Program Management Office in consultation with the FedBizOpps User Group FedBizOpps Program Management Office U.S. General Services Administration Office of Governmentwide Policy Office of Acquisition Policy (MV) 1800 F Street, NW Washington, DC 20405 202-501-0650

TABLE OF CONTENTS 1 INTRODUCTION... 3 1.1 PURPOSE... 3 1.2 SCOPE... 3 1.3 APPLICABILITY... 3 2 APPLICABLE AND REFERENCED DOCUMENTS... 3 2.1 APPLICABLE DOCUMENTS... 4 3 ORGANIZATION AND RESPONSIBILITIES... 4 3.1 CHANGE MANAGEMENT PARTICIPANTS... 4 3.2 RESPONSIBILITIES... 5 4 CHANGE MANAGEMENT PROCESS... 6 4.1 ORIGINATION PHASE... 6 4.2 REQUIREMENTS AND DESIGN PHASE.8 4.3 APPROVAL PHASE... 8 4.4 DEVELOPMENT PHASE... 9 4.5 CLOSURE PHASE... 10 5 CM SYSTEM... 10 6 ADMINISTRATION SUPPORT... 10 7 SOFTWARE QUALITY ASSURANCE... 10 APPENDIX A: BUILD CHECKSHEET... 11 APPENDIX B: REQUEST FOR CHANGE (RFC) TEMPLATE... 12 APPENDIX C: DISCREPANCY REPORT (DR) FORM... 15 APPENDIX D: WORKORDER (WO) RECORD... 16 Page 2 of 16

1 Introduction 1.1 Purpose The FedBizOpps (FBO) Change Management (CM) Plan (CMP) establishes the CM organization roles and responsibilities, policies, guidelines and procedures necessary for controlling and managing technical changes to and maintaining the development and operational FedBizOpps. The guidance outlined in this plan must be incorporated into the engineering activities and management decision-making processes throughout the entire system life cycle from concept and requirements identification to development to system operations and maintenance. 1.2 Scope Change management is a strict discipline in which all FedBizOpps organizations participate. This plan provides for general guidance for the: Procurement Executives Council/Steering Committee (PEC/SC), FBO Program Management Office (GSA Office of Acquisition Policy), FBO Technical Team to include the GSA FSS FBO Technical Manager (GTM), Contractor FBO Technical Manager (CTM), Contractor Deputy Technical Manager (DTM), Lead Developer and Lead Software Quality Assurance Engineer. User Group (Representatives for the FBO Buyer Community) The plan establishes the CM requirements for documenting and controlling changes to the FedBizOpps in order to ensure all approved changes are: 1) necessary, 2) documented correctly, 3) evaluated to consider interfaces, 4) evaluated against available resources, (5) evaluated to deliberate cost vs. benefit, schedule and performance trade-offs, and 6) communicated to Help Desk and the user community. 1.3 Applicability This CM Plan is applicable to the Change management participants for processing Requests for Change (RFC) and appropriate Discrepancy Reports (depending on the scope and schedule/system impacts). The FedBizOpps Program Management Office will maintain the CM Plan. 2 Applicable and Referenced Documents The following documents provide guidance for and are applicable to the FedBizOpps change management activities. In the event of a conflict between these applicable and/or referenced documents and this plan, the conflict should be referred to the FBO Program Management Office. Page 3 of 16

2.1 Applicable Documents Build Check sheet RFC form DR form WO form 3 Organization and Responsibilities Effective Change Management requires active participation from all responsible organizations for the FBO project. The process needs to be fully supported and endorsed by top management. 3.1 Change Management Participants The FBO change management process requires the active support and contribution of the FBO responsible organizations: The FBO User Group The FBO Program Management Office The FBO Technical Team The PEC Steering Committee The FBO Program Management Office serves as the focal point for overseeing the change management process for FedBizOpps. It is accountable for tracking CM requests through the entire cycle from origination to closure to ensure timely and acceptable deliveries to its users. To accomplish this, routine CM changes are to be processed on a continuous basis. The responsible organizations will be enacting major changes by performing the following functions: Processing technical change requests via Requests for Change (RFCs), and Discrepancy Reports (DRs), as appropriate Providing build management support Facilitating communications of changes and impact to the user community and help desk. Controlling CM documentation Providing CM administration Producing CM program metrics. Page 4 of 16

3.2 Responsibilities Participant responsibilities are shown below: The FBO User Group: Reflect and represent the interests of the broad cross-section of Agency Users in conducting its work. Provide user feedback and functionality requirements for FedBizOpps, channeling such requirements to the FBO Program Manager for consideration, including: o Provide review and a functional requirements statement on all proposed system changes. Through its designated Subject Matter Experts, collaborate with the Technical Team and Program Manager to produce a joint requirements specification. o Make recommendations for prioritization of requirements approved by the User Group. o Provide user-supported beta testing for new functionality prior to release to production. o Provide review and comment to revised User Guides and manuals resultant from enhancements and functionality changes to FedBizOpps. The FBO Program Management Office: Perform as the executive agent and Program Manager for FedBizOpps. Operate as the central focal point for FBO, responsible for its management and budget performance. Consider User Group recommendations for FBO. Make the formal recommendations on major changes to FBO to the PEC Steering Committee. The FBO Technical Team/Manager: Perform the day-to-day operational activities of FBO through the FSS FBO Technical Team. Provide technical advice to the FBO Program Manager and User Group on proposed changes Track CM implementation. The PEC Steering Committee: Make decisions on major changes to FBO, after reviewing the recommendations of the FBO Program Manager. Page 5 of 16

4 Change Management Process Origination Requirements & Design Approval Development Closure Figure 1 The FBO Change Management Process Manages FBO Changes From Origination Through Review & Approval To Implementation & Closure 4.1 Origination Phase 4.1.1. Changes Changes to the FedBizOpps system are generally initiated as a result of requests submitted by the FBO User Group, to the Help Desk or directly to the FBO Technical Team from FBO buyer or vendor customers. Regardless of the origination, all changes submitted by FBO buyers or vendors are to be provided to the FBO User Group for consideration. The FBO User Group will evaluate requests for change. Those approved by the User Group will also be prioritized by the User Group and submitted to the FBO Program Management Office. Issues from the helpdesk are to be classified as Work Orders (WOs), Discrepancy Report (DRs), or Requests for Change (RFCs), depending on the scope of the change and whether the request is an actual change or a request to fix a current function of the system. A Work Order (WO) is a change that could be an enhancement or a correction but that requires no more than an incidental amount of resources to implement or correct. The Technical Team will resolve the WO and implements the change without involvement by any other CM participant. Page 6 of 16

A Discrepancy Report (DR) is a report that: o Is made by any member of the technical team or any user o Details an aspect of the system which is not functioning according to the requirements o Requires more than an incidental amount of resources to correct. o Does not require adding to or modifying the requirements document but references existing requirements. The FBO Technical Team will analyze DRs. When appropriate, DRs (depending on the scope and schedule/system impacts) are to be presented to the FBO Program Office and User Group for consideration as a technical change to FedBizOpps. Minor corrections will be made upon discovery with no reporting required. A Request for Change (RFC): o Is requested by the FBO customer (buyer or vendor) o Changes the functionality of the system o o Involves more than an incidental amount of resources to implement. Requires adding to and/or modifying the requirements document. o Processing RFCs are to be provided to the FBO Program Management Office and FBO User Group for consideration. The FBO Program Management Office will view the FBO User Group Chairperson (or designee) as the primary contact representing the collective view of the FBO User Group regarding proposed changes and functional requirements. The FBO User Group is responsible for reviewing Requests for Change (and appropriate Discrepancy Reports) received from the FBO Technical Team or directly from the customer buyer or vendor and determining if the request has value. Those approved by the FBO User Group will be prioritized amongst other pending RFCs. The FBO User Group Chairperson (or designee) is responsible for submitting to the FBO Program Management Office an explanation of the requirement that articulates the performance anticipated from each proposed change and the rationale/benefits that will result from the change. Page 7 of 16

4.1.2 Tracking System The FBO Technical Team will maintain the status of RFCs in a statistical database for the monitoring and review of originators and other FBO Change Management participants. DRs are to be submitted to the Lead Quality Assurance Engineer, assigned a DR number, and entered in the tracking system. Although the WO does not require the comprehensive analysis and development process of an RFC or DR, the WO will also be assigned a number and tracked to closure in the same manner, as RFCs and DRs. Once a change request is documented, the submitter will receive notification that their request was received and will be considered and the assigned DR/RFC/WO change management number. 4.2 Requirements and Design Phase Most changes need to be technically evaluated, prioritized, and estimated in cost/hours, based upon more detailed articulation of the requirement. A. Detailed Requirements Development: The FBO Program Management Office will coordinate with the FBO Technical Team and the FBO User Group in the analysis of the RFCs. The FBO Technical Team will coordinate with the FBO User Group's Subject Matter Experts (SMEs), and will facilitate the joint development of a detailed requirements document. Members of the FBO Technical Team and the designated SMEs execute this process (the SMEs act as duly charged representatives of the User Group). This requirements document should articulate the specific actions taken by the user on FBO and the performance or action that results within FedBizOpps, on a step-by-step basis. B. Design Phase/Technical Solution Development: The FBO Technical Team uses the detailed requirements document to formulate a method or methods by which a solution could be implemented to fulfill the requirement. In the case of complex problems, it is often advantageous to have several options available. The estimated cost for implementing the solution package is prepared. While several Technical Team members will contribute, the Lead Developer is responsible for coordinating this task and compiling the proposed solution package. The FBO Technical Manager will submit its solution package to the FBO Program Management Office. Solution packages are to be periodically grouped into enhancement modules, in approximately six-month intervals. In short, major enhancements will be version-controlled in ordered releases, similar to how commercial software development occurs. The FBO Program Management Office will submit the recommendation to the User Group. C. User Group Value Decision: The FBO User Group, considering the complete solution package, votes whether to continue supporting the solution based on cost and other factors. 4.3 Approval Phase Preliminary to development of each Release, the FBO Program Management Office will present the proposed solution packages for the Release to the PEC/SC for approval. Such Page 8 of 16

presentation should include a description, rationale for changes, performance benefits, and lifecycle cost assessment. In addition, the User Group s views will be included when they disagree with the FBO Program Management Office s recommendations to the PEC for its resolution decision. Upon PEC/SC approval, the FBO Technical Team will initiate development. Changes that are to be denied are either returned to the planning phase for additional work, or rejected and not worked further. 4.4 Development Phase Once approved, developers and quality assurance engineers work together to develop the approved solution in the Implementation phase. Once a change/proposed solution is approved, it is formally scheduled and assigned. During development and testing, VANs will be notified by push email of the change and all details that could aid their accommodation to the change for interfacing systems or business practices. Once the solution is developed, it must undergo testing, including regression testing, prior to release to production. Developers and Software Quality Assurance personnel will work together to certify that the change does what is intended and that it does not create unintended changes elsewhere in the system. In most cases, Quality Assurance personnel will develop a test plan and one or more test procedures so that the tests are repeatable as more mature versions of the change are developed. Once internal testing is complete, the FBO User Group will be provided with detailed requirements specifications. The FBO User Group will provide User Subject Matter Experts (SME) (not necessarily the same SMEs as participated in the Requirements and Design Phase), who will test the solution against detailed requirements specifications at a site to be determined by the FBO Technical Team. The SMEs will annotate the results of their testing and will provide the input to the FBO Program Management Office and to the FBO Technical Team. The FBO Technical Team, prior to release, will correct only those issues identified by the SMEs that indicate the detailed requirement has not been met. Issues identified that are out of scope of the original requirement will be noted as a potential future enhancement or requirement. Once the change has been sufficiently tested, the Lead Software Quality Assurance Engineer signs off on the Build Checksheet. It is then ready to be implemented on the production server. The FBO Technical Team will post an advance change notification on the FBO home page and by e-mail to users to alert the FBO user community of the impending changes, the impacts and benefits, system change interface impact, and related instruction in their use. The FBO User Group will be provided the revised FBO User Guide for review and comment. Page 9 of 16

4.5 Closure Phase Once the Build Checksheet has been completed, the change is installed. The DR, RFC, or WO that generated the change is updated to reflect the new configuration, and, when all items in the DR, RFC, or WO are to be complete, the document is marked closed. If requirements were generated or modified as part of the change, the requirements documentation is edited to reflect the new requirements. Before implementing the change to the production server, the technical staff performs all of the items on the Build Checksheet (see appendix A), or confirms that they have been performed. These items include writing release notes, notifying the help desk, detailing user impact (downtime, etc), notifying users of the change and related instructions, testing, installing the build and updates to documentation. The Checksheet is filed with the Deputy Technical Manager once the build is complete. The RFC, DR, or WO that generated the build is brought up on the CM system and notes are entered as to the solution applied. The Build Checksheet becomes part of the CM database. If requirements were created or modified in the course of making the change, the requirements database is modified to reflect those changes along with appropriate adjustments to FBO system and user documentation. 5 CM System The FedBizOpps Technical Team will use a contractor designed Lotus Notes Database (TBR) to record and track status of Discrepancy Reports (DR), Requests for Change (RFC), Work Orders (WO), and questions on system operation. 6 Administration Support CM administration is needed to support the FedBizOpps Change Management process. The CM administrator plays a key role in providing this support to ensure adequate controls and safeguards have been established and are to be adhered to for proper configuration control. The Lead Software Quality Assurance Engineer provides CM Administration. At a minimum, the CM administrator performs the following functions: RFC/DR/WO and Build Report processing support and pre-build preparation, meeting facilitation, System administration for CM software tools, and ad hoc support to both the contractor and government management and staff. 7 Software Quality Assurance Under the direction of the Technical Manager, the Lead Software Quality Assurance Engineer has established the foundation to build a quality assurance program to ensure CM process policies and procedures are compliant. Ownership of this quality program is not only the responsibility of the Change Management participants but with all government and contractor staff associated with the FedBizOpps program. Page 10 of 16

Appendix A: Build Checksheet FedBizOpps BUILD CHECKSHEET Circle one: RFC DR WO Number: Owner: Testing is complete and passed Modules tested: Release notes have been written and approved Build is scheduled Date: Outage Message drafted, if necessary Outage: Help desk has been notified Help desk has been trained, if necessary User impact has been determined Users have been notified via Website and/or email of impact and outage prior to the build Build Notes: When build is complete, submit this sheet to Deputy Program Manager Page 11 of 16

Appendix B: Request for Change (RFC) Template ORIGINATOR IDENTIFYING INFORMATION Name: Date Prepared: Agency: Phone #: Email Address: Originator Description of Problem/Request/Requirement: Agency FBO Administrator (AFBOA) Review Decision: AFBOA Name, Phone & Email Address: IDENTIFYING INFORMATION [Beginning here, for FBO Project Team Completion, ONLY] Number: (Reference Identifier) Title: Investigator/Originator Name(s): Date Prepared: Projected ERB Date: Date Due to Customer: RFC-01-NNN <<TITLE>> <<NAME>> <<DATE>> <<DATE>> <<DATE>> DESCRIPTION OF PROBLEM/REQUEST/REQUIREMENT Summary of Requested Change: <<SUMMARY>> Scope of this Technical Investigation: Page 12 of 16

<<SCOPE>> Prerequisites (if any): <<PREREQUISITES>> Assumptions (if any): <<ASSUMPTIONS>> Dependencies / Constraints (if any): <<DEPENDENCIES>> Risks (if any): <<RISKS>> Benefits Analysis: <<BENEFITS>> Impact to Users: Time needed for Preparation of this TI: Time required to prepare this TI is <<TIME>>. INVESTIGATOR S RECOMMENDATION Approve per Option <<NUMBER>> ALTERNATIVE APPROACHES CONSIDERED (optional) 1. Proposed Approach Option #1 Approach overview: <<OVERVIEW>> ROM in Work Hours (i.e. estimated hours by task): <<ESTIMATE>> Material cost in dollars (Hardware/Software): <<HARDWARE>> <<SOFTWARE>> Page 13 of 16

Total Hardware and Software Cost: <<COST>> Engineering design concept: CM precautions taken to maintain system integrity: Proposed transition planning: Implementation schedule with milestone descriptions: Impact if Option #1 Approach is Approved: Development O & M Training Other Program Activities Affect on Existing System and Users Including: System hardware, software and/or network footprint. Facilities and/or equipment. User or administrator procedures and processes. Operating environment. Product form, fit or function. System performance. Comment for Option #1 TI: Page 14 of 16

Appendix C: Discrepancy Report (DR) Form Reported by: Phone #: Prepared By: Problem: DR Number: Date reported: Date Prepared: RFC #: Requirement #: Investigated By: Need Date: Technical Investigation: Prerequisites: Risks: Hardware: Software: Resolved By: Resolution: Configuration items affected Time spent working this DR: Page 15 of 16

Appendix D: Workorder (WO) Record Requested by: Date: Summary: WO#: WO-01-NNN Approving Mgr: Implemented on: Implemented by: Page 16 of 16