change management procedures re: the peoplesoft ...€¦ · the change functional consultant is the...
TRANSCRIPT
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