Change Management Procedures Re: The Peoplesoft Application at Mona (The original Peoplesoft document was modified to relate more closely to UWI Mona) See also.. MITS Project Management Methodology & MITS Project Methodology Sample Templates Contents: I. Objectives and Principles II. Definition of Change III. Scope IV. Constraints V. Roles and Responsibilities: Change Manager Working Group or team Change Requestor Change Developer / Technical Consultant Change Functional Consultant Change Stakeholder Change Implementer Security Officer VI. Process Summary VII. Managing the Deployment VIII. Change Request Process (and diagram) IX. Procedures for: Initiating Assessing (see item XI) Authorising Closing X. Change Categories XI. Guidelines for preparing Change Assessment
Objectives and Principles Change in a shared system environment has a wide impact and should be carefully managed to assure quality support and to minimize faults. It is important to plan and schedule all types of change to minimize any adverse business impact. These standards and procedures seek to address the changes in the PeopleSoft environment that are formally initiated by University of the West Indies by reason of requested customizations, or PeopleSoft by reason of software patches and upgrades, or necessitated by hardware changes. Definition of Change Change management assures orderly decision making, implementation and documentation processes for managing change in the PeopleSoft environment. Change management processes and procedures can cover multiple activities of the development cycle. Key points to manage include: a) identifying and approving change requests b) developing and managing the change process c) deploying the change into the production environment. Change Category Descriptions Application Software Change Category Customizations Customizations are modifications to the delivered application software. Typically these modifications change the functioning of the PeopleSoft product in some way. New Development New development creates completely new application objects that provide new or extended features rather than changes to the functioning of the PeopleSoft product. These objects may be attached to the delivered application as bolt-on objects invoked from the Patches and Fixes Major Application Upgrades PeopleSoft application menu. PeopleSoft patches and fixes include any PeopleSoft-delivered or initiated changes other than major PeopleSoft upgrades. Patches and fixes include: Consolidated patches widely delivered on a periodic basis. Interim patches widely delivered as new errors are identified. Short-term fixes delivered specifically as a temporary fix to a locally identified problem. A major application upgrade is a move to a new PeopleSoft Application release. This type of UWI UWI PeopleSoft PeopleSoft
upgrade often involves a major change in functionality. Hardware, Operating System Software Categories Maintenance Reconfigurations Upgrades Maintenance other than routine operational maintenance to keep hardware/software at peak operating performance Redesign of existing systems to take advantage of emerging technologies Modifications to hardware and software systems to keep them at a state of the art status UWI or Sun Microsystems or PeopleSoft UWI or Sun Microsystems or PeopleSoft UWI or Sun Microsystems or PeopleSoft Scope The document addresses both the change request process and the change deployment process. The following table suggests the change manager appropriate to a specific category of change. A change is the addition to, deletion from or alteration of any item in the category. Category PeopleSoft Application Software Customisation business analysis Customisation system development Application upgrade <<-------------------->> Database Update Application of patches Platform issues (ie Windows, LINUX, COBOL, architecture ) Oracle Database Servers Change manager The Application Coordinator (Allison Dundas ) is the change manager for this category except where a specific responsibility is assigned to an analyst / developer who may then assumes the role of change manager for that change DBA team leader Carl Duncan is the Change Manager except where a particular project is assigned to a member of the DBA team (for instance Gary Stines) who then assumes the role of change manager for that change. DBA team lead (as above) Server administration is the responsibility of MITS - Infrastructure. The DBA team (whoever is assigned to the particular issue) will liaise with the appropriate technical engineer from Infrastructure for
database server issues and for application server issues. Networks Client Workstations OS Versions Network interfaces Applications versions (such as Microsoft Office) Application Configurations Application servers Databases Process Schedulers Policies & Procedures Network administration is the responsibility of MITS - Infrastructure. The DBA team (whoever is assigned to the particular issue) will liaise with the appropriate technical staff from Infrastructure for network issues affecting enterprise application services. Hardware administration is the responsibility of MITS - Infrastructure. The DBA team (whoever is assigned to the particular issue) will liaise with the appropriate technical staff from Infrastructure for network issues affecting enterprise application services at the workstation. The core members of the DBA team to be involved (as a team) in all major changes. Change manager DBA team leader Note: currently the core members are Carl Duncan, Gary Stines. 1. Security : (see Security document) - to be maintained by the Security Officer. Applications Manager has responsibility for policy changes. 2. Database integrity, access and distribution : responsibilities documented below 3. Change Management Standards and Procedures : Peoplesoft team will ensure that they are kept abreast with new thinking from Oracle-Peoplesoft 4. Programming Standards team leader (A.Dundas) to keep the team up-to-date on Peoplesoft advice and recommendations in this area Note: The DBA team led by C. Duncan must establish a common approach for all our enterprise systems. All core DBA issues are coordinated through the DBA team leader.
Constraints Ability to obtain user signoff has been an ongoing problem. Users seem timid to sign on a commitment. Where this occurs we will escalate the problem upwards in the chain of command. Roles and Responsibilities The following are the key roles in the Change Management Process. Several roles may be performed by one individual. On the other hand, several individuals could fulfill one role but for different projects. These roles are specific to the Change Management Process for PeopleSoft and though they may be similar to the other applications there might be notable differences from the others. 1. Change Manager The Change Manager manages the Change Management Process for all changes to items or projects to which he/ she is assigned. The Change Manager decides on a case-by-case basis whether a change request warrants the advisory consultation of the Peoplesoft Project Team, product Stakeholders, or MITS Management on the following grounds (see responsibilities of Approver below): a) If the change request is simple, routine, or clearly unacceptable, the Change Manager may use discretion to approve or deny the request without additional consultation in order to expedite problem solving. b) If the change is extensive and has not yet been included within the team s scope of work it must first be brought to the Peoplesoft Project Team for discussion or alternatively be discussed with MITS Applications Manager to arrive at a determination of resource, schedule and possibly cost c) All changes must be communicated to all members of the project team by the specific Change Manager unless someone else is designated so to do. The Change Manager is also responsible for ensuring that Change Tracking information is maintained. Change Tracking responsibilities should however be delegated to the actual individual with primary responsibility for executing the change. Responsibilities include: Manage production of the outcome Manage the movement of change requests through to approval taking place during production, recognizing where consultation is required Convene the change management meetings as required. This is done as an extension of the PS team meeting or through the DBA Produce minutes of change management meetings including current status of all open Change Requests. Update the appropriate stakeholders frequently. Meeting notes to be taken by a team member named at each meeting. To be included in our document repository as a record.
Advise appropriate parties of the status of the change. Frequent updates must be sent to the appropriate stakeholder by the person primarily responsible for managing the change Verify closure of change. A specific procedure for closure must be followed. A signoff document must be produced for the users to signify their acceptance or indicate their problems or comments or rejection. Where upgrades have taken place, this must also be signed off or commented by the primary MITS team member who is executing. (see Template submitted for suggested, not mandatory, use). The person responsible for execution is to carryout this task. If there is a difficulty it must be escalated to the Change Manager or MITS management. The job of the Change Manager is similar to that of a project manager and so standard PMI principles are called on. Change Tracking responsibilities summarized: Maintain change log with the status of Change Requests from inception through closure. Verify the Change Requests are correctly completed. Ensure all signoffs are obtained in accordance with the change management procedure. Notify appropriate parties of Change Request status. Create Change Management Reports as necessary. Keep stakeholders informed 2. Change Management Working Group ie MITS Peoplesoft (PS) Team The team co-opts the efforts of the MITS System Engineers and LAN Administators as necessary. Primary users from the HR Department and Payroll may also be co-opted as necessary for a specific project. The Working Group provides a forum to review Change Requests on a regular basis. The Change Management Working Group is comprised of MITS members of staff. The Change Manager convenes the meetings for his/her appropriate project. Responsibilities include: Assess and prioritize Change Requests. Approve or secure approvals for Change Requests. Rationalise resources Assess the benefit of the change in relation to cost. Assess the business risk and impact of the change. Ensure that the technical feasibility, risk and effect of the change have been adequately assessed. Approve or reject the Change Request.
3. Change Requestor The Change Requestor initiates the change process. Requests may come from a user department or be initiated from within the Peoplesoft Project Team. All user requests must be submitted in writing. User requests must be signed by the HOD or manager responsible for the area of work, and must be submitted through the Functional Administrator. Responsibilities include: Specify the requirements. This should be done in collaboration with the Change Functional Analyst. Identify the business, service or technical need for the change. Define the success criteria for the change. Categorize the change. Propose the change solution in business or technical terms as appropriate. Propose a date by which the change is needed. Identify the affected parties or area or business. Submit Change Requests for approvals Attend change request meetings as required. The Request template is available from the MITS Website http://www.mona.uwi.edu/mits/services/ 4. Change Developer / Technical Consultant This is referring to the person(s) on the PS team to whom the technical tasks are assigned. For application changes this would include the application developer / system analyst Responsibilities Include: Scope the impact and the level of effort required to implement the change: -identify those groups needed to provide resources and skills for the change -identify the technical solution -assess the integrity of data and databases affected by the change -propose milestones for the change implementation -propose the schedule for the change implementation Create the technical documentation Attend the Change Management Working Group meetings as required.
5. Change Functional Consultant The Change Functional Consultant is the person who provides the skill and resources to assess the Change Request in functional terms. This is usually the primary user in the functional department. Depending on the scope of the change this function may be carried out by or through the HRMIS team. Often the functional consultant is also the change requester. Responsibilities include: Collaborate with the Requester on the requirements specification Assess impact on internal processes and resources Revise the business processes as necessary Identify internal resources to support and implement the change Evaluate cost / business benefits to justify the change Attend the Change Management Working Group meetings as required 6. Change Stakeholder Different parties have a stake in the quality of the outcome and the impact of changes to specific items on the PeopleSoft list of products. Parties that have an interest in a particular product are generically referred to as the Change Stakeholder for that product. Their interest must include their responsibility to accept the change completed or reject it for specific reasons. The stakeholder must: Carry out appropriate tests as instructed and provide input on impacts of the change Attend change management meetings as required Approve the results at various stages of the change development, i.e. functional specification, implementation planning and acceptance testing 7. Change Implementer See below Managing the Deployment of the Change to the Production Environment The Change Implementer is responsible for placing the solution to a Change Request into practice. In our establishment this person is likely to be the same as the Change Functional Consultant. Depending on the change the activities may include: the activities that promote the change to the production environment implementing changes in workflow
creating user documentation establishing user testing user training verification of the proper functioning of the change solution after it is in use The change implementer must advise the appropriate persons, including the Peoplesoft team, of the deployment completion. See deployment details below. 8. Security Officer Updates the necessary Role/Permissions as appropriate for the respective user groups. Process Summary The PS Team (see above under Change Management Working Group) will be the working body through which a) Change requests are received b) Change requests are initiated eg upgrades and patches c) tasks are planned / prioritised, d) status discussed and managed e) test strategy is managed f) policies and practices governing change management are ratified. This is done within the overall context of the Department s project commitments. Persons are assigned technical responsibility for a particular task (or project) and are expected to manage the change as discussed above. Changes involving upgrades and patches must be coordinated by the DBA team leader (or someone particularly assigned). It is expected that the primary Peoplesoft DBAs will be the persons through whom these tasks are execute but there must NOT be only one person involved in executing, as part of our business continuity rules. Coordinating through to execution must follow the procedure below : a) Determine the strategy - output to be a work plan which becomes a record for filing. Where there is a significant project to be executed the strategy must be worked out among the group or by the DBA team leader and circulated to the DBA team for comment and affirmation. The resources assigned must be named in the plan. b) Execute the plan one of the persons involved must be responsible for recording the process. The record should constitute the steps executed, the results, associated comment. Include print outs if necessary c) Carry out appropriate tests to ensure that the environment has been restored. It may be necessary to involve other members of the Peoplesoft team to verify this process. A test report must be produced to attest to the fact that the environment has been re-established.
d) Where an elaborate upgrade is being planned the test plan must be married to the strategy determination. In this case the application change manager must be involved in the planning process to ensure that the necessary application testing is planned into place Note: the upgrade procedure is designed to ensure that the technical knowledge is shared by more than one person. This is important for business continuity assurance. Team evaluation after the fact : the team must discuss among themselves in a team meeting, the project and the results. The purpose is to evaluate i) how well done ii) issues encountered with a view to correcting for the next process. This may be an informal get together for small projects, whereas for larger projects, or where significant problems have occurred, group meeting must be called for a structured evaluation. This is the responsibility of the respective Change Manager.
Managing the Deployment of the Change to the Production Environment Abstract: we have had a long period of discussion on the subject of deployment trying to resolve the following conflicting issues: a) that a working knowledge of the application is an important consideration in the deployment of intricate and extensive application changes, thus a developer or system analyst must be involved in deployment b) that best practice rules dictate that the developer ought not to have deployment access to the system these responsibilities to be divested in two different technical functionaries the developer and the database administrator c) that there are emergency demands requiring immediate fixes and a database administrator might not be available at the specific time d) that the DBA is answerable for the integrity of production system We will operate as follows: All development will take place on the development database. Changes to be fully tested in this environment by the Change Developer. Each Change developer may require a separate development database when two or more are working independently on different aspects of the system. The DBA will ensure that a development database is established for each application developer as and when necessary. Each application developer will be responsible for maintaining a copy of his current work-in-progress. However the development systems will be backed up in the normal procedures conducted by the DBA, on request and for the duration of the work-in-progress. The application developer/problem solver will be allowed read-only access to the production database as their typical mode of access. This is necessary to allow MITS to carry out investigation for problem solving. In addition to the above the application developer/problem solver will be entrusted with a separate access code for full access specifically to enable change deployment and emergency response. This account is referred to as the DBA account and must be auditable. By default, it is locked and can only be unlocked using another account with connect privileges only. After connecting with this restricted account, the developer will run a prescribed select statement to unlock the DBA account. When the account is unlocked, a notification email is sent to all developers and the DBA team. The developer is required to respond to the notification email detailing the reason for accessing the Banner production environment. This will keep the DBA team informed with what is happening and better equip them in providing comprehensive audit information. A scheduled job will lock the DBA account at 12 midnight each day.whereas, in an appropriately resourced environment the deployment to production would be the purview of the DBA, the UWI Mona developer responsible for the change has to be enabled to carry out this exercise where customization or add-ons have been done. As far as possible there must be another member of the team involved in the deployment.
Users may be asked to carry out preliminary testing in the development databases but this is left to the judgment of the Change Developer. However, before deployment to production, user testing must take place on the Test instance of the database which is a copy of production. Proof of test must be documented for reference and to satisfy our auditors. In order to remove or limit the possibility of one person s set of changes creating consequences for another set with two persons often needing to test within the same timeframe, Change Developers will communicate to the team (and in particular to the DBA) their need for and the timeframe for use of the Test database The Test database must be structurally alike to the production database but the data will be older. Data currency is not required for testing. The appropriate MITS technical person or team will test all changes and upgrades as thoroughly as possible before passing on to the test database for user testing. Proof of test must be documented for reference and to satisfy our auditors. The critical user or the Change Functional Consultant (on behalf of the application owner) must always confirm compliance of the change in relation to the stated requirements or expected outcome. When there is a software upgrade, all the functions in use must be tested to ensure that there are no undue occurrences perceivable by the user. This is carried out on the test database. A report of the test must be documented for reference and for audit. The Security Officer is to be given a list of the new/changed pages for update of the appropriate permissions/roles in production. We modify our processes from time to time and we will continue to do so. The internal operating rules documented here will be superseded by those defined in the internal documents DBA Task Profiles and SYSADM Password should there be any mis-alignment.
Change Request Process and Procedures 1. Initiate Change is completing and submitting a Change Request and logging the Change Request as received. 2. Assessing Change includes two major activities. The first is to secure a business and/or technical assessment for the change if the additional assessment information is needed to fully evaluate the change. Second is appraising and prioritizing the proposed Change Request for business and technical issues and business value and impact. 3. Authorize Change is approving or rejecting the Change Request. Approved Change Requests are forwarded to the person who will develop the solution. 4. Secure Escalated Approval is getting approval for Change Requests that require approvals from a higher level or additional authority. 5. Schedule, Develop and Implement Solution is outside of the Change Request Process. It is comprised of the activities of developing the solution, acceptance testing and implementing the solution. 6. Close Change is logging the Change Request as closed when notified that the change has been implemented. It also involves creating a backup strategy for the change and documentation of steps necessary to recover or reapply the change if necessary after a major upgrade.
Procedure - Initiating Action by: Change Requestor Action taken: Determines the need for change. Completes the Change Request Form. Sends the Change Request Form to the Change Manager. Change Manager Reviews Change Request Form for completeness. If the Change Request Form is incomplete, returns the Change Request Form to the Change Requestor. Logs receipt of the Change Request in the Change Log. The Change Request is presented to the Change Management Working Group.
Procedure: - Assessing Action by: Change Manager O Action taken: Requests feedback from Stakeholders and Change Management Working Group on any known impacts of the change. If additional technical or functional assessment is required, notifies the change requestor. o Notifies the appropriate Change Technical Consultant and/or Change Functional Consultant o Reports this to MITS Peoplesoft Project team Change Technical Consultant and/or o Prepares the Change Assessment o Delivers the Change Assessment to the Change Manager. Change Functional Consultant Change Manager o Logs the receipt of a Change Assessment. o Reviews open Change Requests and determines need to convene the Change Management Working Group Meeting. o Invites product Stakeholders and other interested parties to a Change Management Working Group meeting as needed. o Convenes the Change Management Working Group as needed. Change Management Working Group Reviews Change Requests and any accompanying Change Assessments. Prioritizes the Change Requests based on type, complexity and need.
Procedure - Authorising Action by: Change Management Working Group ie MITS PS team Change Manager Action taken: Reviews the list of prioritized Change Requests. Determines if the Change Request requires higher level Approval otherwise approves or rejects If the Change Request requires Escalated Approval, sends the Change Request to the appropriate escalated Change Approver authority. Change Manager Logs the decision in the Change Log. Notifies the Change Requestor and Change Stakeholders Brings it to the MITS Peoplesoft Project Team for assignment to a Change Technical Consultant Procedure - Closing Action by: Change Implementer Change Manager Action taken: Notifies the Change Manager that the change has been Implemented Exports the project to file (in accordance with naming conventions) in predefined area for backup purposes. Notify DBA of change implementation by email containing the name of the exported project Completes a change completion form See procedures defined below under Managing the Deployment of the Change to the Production Environment? Logs the Change Request as closed in the Change Log Notifies the Change Requestor, Change Stakeholders and Change Management Working Group of the closed Change Request.
Guidelines for Preparing a Functional or Technical Change Assessment Include the following information in the assessment: Information about Assessor Assessors Name Assessor s Title Organization Phone Number E-mail address Change Request Details Assessment Change Request Number Detailed Description of Change Estimated time to make the change Required approvals Functional Assessments List possible functional risks List possible functional benefits Impact upon Project Schedule Cost impact Impact on existing policies Impact on other PeopleSoft modules Technical Assessments List possible technical risks List possible technical benefits Impact upon Project Schedule Impact upon Performance Cost impact Impact on other dependent system hardware or software Impact on other PeopleSoft modules