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.

UWI

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

PeopleSoft application menu.

UWI

Patches and Fixes 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.

PeopleSoft

Major Application

Upgrades

A major application upgrade is a move to a new

PeopleSoft Application release. This type of

PeopleSoft

upgrade often involves a major change in

functionality.

Hardware, Operating System Software Categories

Maintenance Maintenance other than routine operational

maintenance to keep hardware/software at

peak operating performance

UWI or Sun

Microsystems or

PeopleSoft

Reconfigurations Redesign of existing systems to take

advantage of emerging technologies

UWI or Sun

Microsystems or

PeopleSoft

Upgrades Modifications to hardware and software

systems to keep them at a state of the art

status

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 Change manager

PeopleSoft Application Software

• Customisation – business analysis

• Customisation – system development

• Application upgrade <<-------------------->>

• Database Update

• Application of patches

• Platform issues (ie Windows, LINUX , COBOL,

architecture )

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.

Oracle Database

DBA team lead (as above)

Servers

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

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.

Client Workstations

• OS Versions

• Network interfaces • Applications versions (such

as Microsoft Office)

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.

Application Configurations

• Application servers

• Databases

• Process Schedulers

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 .

Policies & Procedures 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: Action taken:

Change Requestor • 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: Action taken:

Change Manager

O

• 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

Change Functional

Consultant

o Prepares the Change Assessment

o Delivers the Change Assessment to the Change Manager.

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: Action taken:

Change Management

Working Group ie MITS

PS team

• Reviews the list of prioritized Change Requests.

• Determines if the Change Request requires higher level Approval otherwise approves or rejects

Change Manager • 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: Action taken:

Change Implementer • 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?

Change Manager • 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