KIDS Program

VersiFit Change Management Plan

January 14, 2009

Version 1.0

Revision History

Date / Version / Description / Author
January 5, 2009 / 0.5 / Initial Draft / Debbie O’Connor
January 14,2009 / 1.0 / Updated for requested changes / Debbie O’Connor

Reviewers

Name / Title
John Flowerday / KIDS Team Lead
Dennis Boston / Project Manager
Nell Klumph / QA
Joel Robe / Program Director
Baron Rodriquez / CIO

Approvers

Name / Title
Joel Robe / Program Director
Baron Rodriquez / CIO

Distribution

Project Team and Stakeholders
KIDS Team-Joel Robe, John Flowerday, Garry Dixon, Melinda Weinmann, Corrina Fisher, Rob Magee, Chris Edison
1

Table of Contents

1Introduction

1.1Purpose

1.2Scope

2Change Control Process

2.1Change Control Process Diagram

2.2Submitting a Change Request

2.2.1Completing the Change Request Form

2.3Change Approval

2.3.1Internal ODE System Changes

2.3.2Regional Provider System Changes

2.3.3Approved Changes

2.3.4Rejected Changes

2.4Completing the Change

2.5Change Control Log

3Change Request Form

4Change Control Log

Appendix A

1

Change Management Plan

1Introduction

This is the VersiFit Change Management Plan for the KIDS IIIProject. The Change Management Plan will be incorporated into and become a formal part of theKIDSProgram’s Project Management Plan.

1.1Purpose

The purpose of the Change Management Plan is to describe and document how changes to the project and its assets will be completed including:

  • Project Management Plan and its subsidiary plans
  • Milestones
  • Deliverables
  • Time
  • Cost
  • Scope
  • Risks
  • Quality

1.2Scope

Key references supporting this plan are on the KIDS Project website.

The scope of this plan includes:

  • Project Charter
  • Scope Statement
  • Project Management Plan (includes document version control and all sub plans)
  • Project Schedule
  • Training schedules, agendas, and documentation

1

2Change Control Process

2.1Change Control Process Diagram

2.2Submitting a Change Request

All Change Requests will be sent to the KIDS Project Manager for initial review.

2.2.1Completing the Change Request Form

The requester must fully complete page one of the Change Request form prior to sending to the KIDS Project Manager. Incomplete forms will be returned to the requester. Any information on the form that requires further clarification will be reported back to the requester prior to the proposed change being logged and entered into the change approval process.

2.3Change Approval

At the onset of the change approval process, appropriate level stakeholders will be notified that the change was received and entered into the process. The complete scope of the change will be considered for determining the approval level. For most changes approval will be granted by the Program Director and/or Program Sponsor.

2.3.1Internal ODE System Changes

Changes that are planned to be made to internal ODE Systems must follow established Change Management processes at ODE. The process outlined in this document merely approves or rejects changes from a project perspective but does not approve the change at the ODE systems level. See Appendix A for the Internal ODE change process. John Flowerday, KIDS Team Lead, will coordinate all internal ODE System changes.

2.3.2Regional Provider System Changes

Changes that are planned to be made to Regional Provider systems must follow established Change Management processes at the Regional Provider. The process outlined in this document merely approves or rejects changes from a project perspective but does not approve the change at the Regional Provider systems level. This item will be further discussed and refined during the requirements phase.

2.3.3Approved Changes

When the change is approved the requester will be notified. The change will then be sent to the appropriate party for completion.

2.3.4Rejected Changes

Changes that are rejected will be sent to the requester with the reasons for rejection documented on the Change request form.

2.4Completing the Change

Once the change is approved the appropriate person/organization/project will be notified to complete/document the completion of the change. Upon completion the Project Manager will be notified. The Project Manager will complete any changes necessary to project documentation and will then complete the entry in the Change Control Log.

2.5Change Control Log

When a change is accepted and the approval process is set in motion the change will be logged into the Change Control Log and assigned a change number. Once the change is completed the Change Control Log will be updated with the completion information and the change is closed out. A rejected change will be logged as such on the Change Control Log.

3Change Request Form

The following form is an example of the actual Change Request Form. You can download the Change Request Form at the VersiFit KIDS IIIProject website.

Request No.
Bridge Trak #
Request Title
Notice Date / Author
Description of Change Request or Issues
Justification/Impact

To be completed by VersiFit ProjectManager

VersiFit Change/ Issue Control Number / Client ProjectManager / Submitted Date

To be completed by Assigned Business Analyst

Date / Additional Change/Issue Information
Action Plan
Solution:

Impact Analysis[1]
Versifit Resource
Requirements / Project Plan Adjustment / Estimated Cost
Action Plan Disposition
Project Team Review Date / Approved / New Change Request / Investigate / Cancel
Customer Review Date / Approved / New Change Request / Investigate / Cancel

To be completed by KIDS ProjectManager

Change Control Disposition
ProjectManager / Documentation Verification Date / Requester Documentation Package Sent / Closed Date / Closed Reason
C = Completed Change Control
NCR = New Change Request
X = Canceled

KIDS Team Lead Signature

Program Director Signature

Change Description
# / Change Description / Build / Table / Column / Document
Change Description Attachments
# / Title

1

4Change Control Log

KIDS IIIProject Change Control Log
Date / Change Control Number / Requester / Change Description / Approved / Rejected / Completed

1

Appendix A

ODE Contractor Development Rollout Process

As of 08/08/08

John Flowerday and Larry Hartzell are the onlydevelopers that roll Applications to Production. ALL Rollouts to PRODUCTION are to be conducted ONLY on Thursdays between 6AM – 8AM unless early rollout is approved.

DEV Database: ODESQLDEV\PRODDEV Web Server:

TEST Database: ODESQLTEST\PRODTEST Web Server:

PROD Database: ODEOPERV\PRODPROD Web Server:

Development Rollout Process for Contractors

  1. Application Introduction to ODE Technical Staff:
  2. Data owners need to set up a meeting with technical leads (Gary Ellwanger, Josh Klein, Daron Wall, Larry Hartzell, John Flowerday & Baron Rodriguez) to introduce the Application to ODE Technical Staff. This needs to happen before any development starts by the Contractor and should happen before the contract is written. Topics to cover include:
  3. Introduction of application and the need it is filling
  4. Security – how will security work, who are the users (audience)
  5. Special requirements that fall outside of ODE Technical Standards and Coding Practices
  6. Who will maintain this system over time
  7. Where will it reside on DEV, TEST & PROD
  8. Timeline & Priority
  9. Get a BridgeTrak Issue: Your ODE Technical Contact is Daron Wall.
  10. All projects must have a BridgeTrak issue for managing user acceptance and rollouts. Gary Ellwanger can help with getting this BridgeTrak Issue.
  11. Try to have your ODE technical contact (Daron Wall) add an entry to the Rollout Schedule AS SOON AS YOU BEGIN development.
  12. Develop in DEV: ODE has DEV, TEST and PROD environments.
  13. Contractors develop on DEV over a VPN connection. (If you are developing offsite or somewhere other than ODESQLDEV then you will need to have ODE roll out your project to DEV and TEST.)
  14. Check code into the ODE Visual SourceSafe as you develop. (All .NET 2.0 Web rollouts from DEV to TEST are rolled from VSS. Rollouts from TEST to PROD are rolled from the TEST server. Unless the Contractor works out other arrangements with John Flowerday.)
  15. Work with ODE data owners to create a test plan before you start developing. The test plan is a measure of your success. You will not have a successful project without this.
  16. Application Handoff: Only for the first time the Application is rolled out.
  17. The first time an Application is rolled out the Contractor and Data Owner needs to arrange an “Application Handoff Meeting” with the ODE Technical Contact (Daron Wall).
  18. Arrange a meeting with Daron Wall, John Flowerday and Larry Hartzell to review that the Contractor has met ODE standards and coding practices.
  19. Roll to TEST: After development and testing is finished in DEV then roll out your project to TEST.
  20. Email ODE Helpdesk (CC Daron Wall) to roll to TEST. Give at least 48 hours lead time.
  21. Database Rollout: Contractor is to provide ODE with a back end database script and specify the database name. Add a “USE [DB Name]” command at the top of all DB scripts.
  22. Web Rollout: Contractor is to provide ODE with a list of front end files that need to move as well as the source & target servers and directories.
  23. User testing in TEST: Gary Ellwanger will assign the issue to the User for testing in TEST.
  24. The Data Owner or User must test the rollout in TEST. If the TEST rollout was not successful then fix it in DEV and have it rolled to TEST again.
  25. After having a successful test in TEST then Gary Ellwanger will add a comment to the ticket saying, “Testing was successful. Ready to publish to PROD” and assign the ticket to Daron Wall.Issues must be received prior to 3PM Wednesdays to ensure rollout to PROD on Thursdays.
  26. Rollout to PROD on Thursday: Rollouts to PROD are on Thursdays between 6AM – 8AM.
  27. Before we will roll out a project to PROD there must be an Action entered into the BridgeTrak issue saying, “Testing was successful. Ready to publish to PROD.”
  28. DaronWall will schedule the project for roll out in the rollout schedule and BridgeTrak Issue.
  29. The project will be rolled out on Thursday between 6AM – 8AM unless early roll out is approved.
  30. Acceptance testing in PROD:
  31. After the rollout the Contractor and Data Ownershould conduct acceptance testing in PROD.
  32. The Data Owner should continue to monitor that the project is working correctly in PROD.

1

[1] If any part of the Impact Analysis section is not applicable, complete the section with N/A.