Multi-Factor Authentication Project Charter 11gR2 Upgrade Project Charter Page 1 Project Charter...

OIM 11gR2 Upgrade Project Charter

Project Charter

Project Name: Oracle Identity Manager 11gR2 Upgrade

Project Name Oracle Identity Manager 11gR2 Upgrade

Project Manager Ching-tzu Chien Organization DoIT

Shannon Larson DoIT

Sponsor Lorie Docken Organization UWSA

John Krogman DoIT

Elena Pokot UW-Whitewater

Customer Al Crist

Organization Associate Vice President, UWSA Human Resources & Workforce Diversity

Larry Henderson Director, UW Service Center

Document Date September 17, 2013

Prepared By: Shannon Larson Position: Project Manager Date: September 17, 2013 Version No: v5


Project Charter Approval Signatures

Project Name: Oracle Identity Manager 11gR2 Upgrade

Project Manager _______________________________________ __________________ (Signature) (Date)

Ching-Tzu Chien, Project Manager, UW-Madison-DoIT-Application Development and Integration

Project Manager _______________________________________ __________________ (Signature) (Date)

Shannon Larson, Project Manager, UW-Madison-DoIT-Application Development and Integration

Project Sponsor _______________________________________ __________________ (Signature) (Date)

Lorie Docken, Associate Vice President (interim), UWSA

Project Sponsor _______________________________________ __________________ (Signature) (Date) John Krogman, Chief Operating Officer, UW-Madison DoIT Project Sponsor _______________________________________ __________________ (Signature) (Date) Elena Pokot, Chief Information Officer, UW-Whitewater Project Customer


_______________________________________ __________________ (Signature) (Date)

Al Crist, Associate Vice President, UWSA Human Resources & Workforce Diversity

Project Customer _______________________________________ __________________ (Signature) (Date)

Larry Henderson, Director, UW Service Center

Document Change Control

The following is the document control for the revisions to this document.

Version Number

Date of Issue

Author(s) Brief Description of Change

V1 08/09/2013 Shannon Larson Initial version for review and comment

V2 08/16/2013 Shannon Larson Changes based on comments and feedback.

V3 08/21/2013 Shannon Larson Updated Governance structure

V4 08/22/2013 Shannon Larson Overall document updates.

V5 09/17/2013 Shannon Larson Update project governance structure.

Definitions

The following are definitions of terms, abbreviations and acronyms used in this document.

Term, Abbreviation or Acronym

Definition

DoIT Division of Information Technology

HRS Human Resource Systems

Single Identity A given person will have only one user account that is used to access the enterprise system (HRS, SFS, etc).

OIM Oracle Identity Manager

SME Subject Matter Expert

Lead Project Manager

Project Manager from the UW System


Project Manager Project Manager selected from the vendor


Table of Contents

1. Executive Summary ..................................................................................... 1

2. Scope ................................................................................................................................ 1

2.1 Business Need ......................................................................................................... 1

2.2 Project Goals ............................................................................................................ 2

2.3 In Scope/Out of Scope ........................................................................................... 3

2.4 Critical Success Factors ....................................................................................... 3

2.5 Project Assumptions .............................................................................................. 3

2.6 Project Constraints ................................................................................................. 4

2.7 Project Deliverables ............................................................................................... 4

3. Requirements ............................................................................................... 4

4. High-Level Milestones and Timeline, Roles and Budget .......................... 4

4.1 High-Level Milestone and Timeline for OIM Upgrade: .................................. 4

4.2 High-Level Roles ..................................................................................................... 5

5. High-Level Control Strategies .................................................................... 6

5.1 Communications Strategy .................................................................................... 6

5.2 Quality Management Strategy for OIM Upgrade ............................................. 6

5.3 Issue Management Strategy ................................................................................ 6

5.4 Change Management Strategy for OIM Upgrade ............................................ 6

5.5 Risk Management Strategy .................................................................................. 7

5.6 Procurement Strategy ............................................................................................ 8

1. Executive Summary The IAM Steering Committee and Common Systems Review Group (CSRG) has authorized and funded the upgrade of the current OIM 10g infrastructure to OIM 11gR2. In short, this project will entail installing the OIM 11gR2 environment, documenting detailed technical requirements, configuring and customizing the infrastructure to meet current functionality, quality assurance testing, and deployment to HRS. The current Identity and Access Management (IAM) provisioning system is an implementation of Oracle Identity Manager 9.1.0.2. Since its deployment, it has been used to provision user accounts to the PeopleSoft HRS system. IAM is configured to use UW’s PersonHub system as the authoritative source for its user base. Using this system, employees and persons of interest (POI) can be provisioned accounts and access in HRS. Modifications can be initiated through user requests made to IAM or automatically based on information available in PersonHub. The current system has undergone several customizations to the vendor provided solution in order to facilitate the requirements necessary to provision to HRS. The majority of the modifications were made to promote the general usability of the vendor application, which HRS users found to be lacking. In the newest release of Oracle Identity Manager, the user interface has been redesigned from the ground up to address the general concerns with usability. The rest of the modifications to the IAM system were designed to address HRS’s specific business requirements. The project has a tight timeline of 11-12 months for full implementation into production and a budget constraint of approximately $410,000.

2. Scope 2.1 Business Need Currently, the IAM system is limited to provision to a single instance of PeopleSoft. This means the current system cannot support provisioning to the HRS PeopleSoft instance and other PeopleSoft instances, such as Shared Financial System (SFS). This drawback has been addressed in the new version of Oracle Identity Manager; the 11gR2 release can provision to an unlimited amount of PeopleSoft applications. With the 11gR2 release, many additional features have been added to enhance the user experience and simplify the configuration of the platform. Many of these items can be used to improve the functionality and usability of the UW System IAM infrastructure. They are as follows:

Simplified Self Service - Improving the user experience was the single greatest focus on the OIM 11gR2 release. Oracle received input from

customers about the usability of previous versions and made the newest release much easier to understand and use.

Delegated Administration - One of the biggest enhancements in 11gR2 is the introduction of fine-grained administration using organizations.

Extensible User Interface - This framework allows UI customizations to be performed in the browser without any additional programming or scripting. These customizations are also applied in a way that they will survive patching without any additional effort. In addition, these customizations can easily be packaged and deployed across multiple environments.

Configurable Approval Processes - One of the features the DoIT security team is most anticipating is the ability to configure the SOA-based approval processes.

Comprehensive Audit and Compliance Management - Oracle Identity Manager provides extensive tools for auditing users’ access. For example, if a user changes jobs or leaves the organization, it’s important that his or her access be deprovisioned as soon as possible to mitigate risk. Reports can help indicate if deprovisioning isn’t happening in a timely manner.

End User Level of Data Access - A common feature enhancement of the current IAM system is a simplification of the level of data access requests. After the upgrade, the users will be able to select the exact level of data access that they require, rather than be locked into the levels available in the current system.

End User Simplified Request Process - The enhanced request process greatly reduces the complexity of the request process in the current IAM system.

End User Enhanced Request Approval - Part of the vendor provided functionality with Identity Manager 11gR2 is the separation of the requested resources in the approval process. An approver can apply separate decisions to each requested resource. For example, they can approve one HRS role, deny another, and return a third to the requesting user for additional information.

End User Delegated Administration - Allowing DoIT security to handle the administration of resource visibility is a big advantage to upgrading the environment. Using advanced security features, DoIT security will have the capability to assign resources to certain organizations as a means of limiting access. Organizational scoping will allow DoIT security to more freely delegate administrative tasks to power users.

2.2 Project Goals The purpose of the OIM Upgrade project is to install the OIM 11gR2 environment, document detailed technical requirements, configure and customize the infrastructure to meet current functionality, test quality assurance, and deployment to HRS so that

1. System efficiency is improved; 2. Quality of service and number of defects are reduced; 3. Organizational reliance on external staffing sources is reduced or

eliminated; 4. Effort required to perform work is reduced.

2.3 In Scope/Out of Scope

In Scope

Installing the OIM 11gR2 environment; documenting detailed technical requirements, configuring and customizing the infrastructure to meet current functionality, quality assurance testing, and deployment to HRS.

Out of Scope

Additional enhancements not enabled by the vendor provided product. Examples include:

1. The timeout escalation for approvals should consider business days, rather than just a fixed amount of time

2. Provide requesters the ability to edit a request after pressing submit changed in a role request window. This will prevent requester from having to redo the entire request in case of a mistake.

2.4 Critical Success Factors 1. Clear, timely and regular project communication to project stakeholders; 2. The IAM Steering Committee reviews and approves the technical solution; 3. The Project Sponsors and Customers are participating in project

communication process and are able to make timely decision; 4. Stay within budget and timeline.

2.5 Project Assumptions 1. The project has the full support of project sponsors, stakeholders, and

customers;

2. A group of core users will participate in the integration design review process;

3. A group of core users will participate in testing activities prior to deployment;

4. The project sponsors or project leads will provide additional resources when

necessary;

5. The purpose of this project will be communicated throughout the core user

community prior to deployment;

6. IAM Steering Committee will lead the collaborative effort to move forward with

the onboarding of HRS to the new Architecture with existing functionality;

7. HRS/SC will provide DoIT Security, QA testing, environment management,

training, and communication resources to onboard the HRS application to the

new infrastructure.

2.6 Project Constraints 1. Any coding/modification that needs to be done by the IAM Development

Team will need to have the time/resources/priority approved by the IAM

Steering Committee;

2. Changes in technologies and/or requirements may require changes to OIM;

3. Estimated IAM budget of $410,000;

4. Resources – The project requires resources from IAM, HRS Service Center

and DoIT Security. The functional managers of these three units must provide

resources on a timely basis;

5. User and quality assurance testing.

2.7 Project Deliverables

1. Upgrade OIM 10g to 11gR2, leveraging vendor-provided functionality. a. Document detailed technical requirements; b. Configure the infrastructure to meet current functionality; c. Quality assurance testing; d. Deploy to HRS; e. Application migrated to the new environment; f. Decommission of the old environment; g. Knowledge transfer from vendor to UW System (support and staff); h. Training:

i. End-user for requestors and approvers. ii. Admin for DoIT Security. iii. Infrastructure for IAM Support Desk.

i. Update Knowledge Base (KB documents).

3. Requirements A complete list of business requirements is located at project’s wiki website: https://wiki.doit.wisc.edu/confluence/display/TBD

4. High-Level Milestones and Timeline, Roles and Budget 4.1 High-Level Milestone and Timeline for OIM Upgrade:

Key Milestone Target Date Prepare the Organization October 7, 2013 – October 18, 2013 Determine Target System October 21, 2013 – November 15,

2013 Determine Architecture Requirements November 18, 2013 – January 10,

2014

https://wiki.doit.wisc.edu/confluence/display/SFAUTH/Business+Requirements

Install Software January 13, 2014 – February 21, 2014 Document Technical Requirements January 13, 2014 – February 21, 2014 Configuration February 24, 2014 – August 8, 2014 Training August 11, 2014 – October 3, 2014 QA Testing August 11, 2014 – October 3, 2014 Migration to Production October 6, 2014 – October 10, 2014

Comments: The target dates for the above timeline are estimates and are subject to change based on the number of customizations required to meet the business’ needs. This has a direct effect on the number of resources required. 4.2 High-Level Roles

4.2.1 Project Governance Structure

Executive Committee

Project Sponsor

Lorie Docken

John Krogman

Elena Pokot

Project LeadTy Letto

Stefan Wahe

Lead Project ManagerChing-tzu Chien

Shannon Larson

CustomerAl Crist

Larry Henderson

Key Stakeholders CIO Council (Lorie Docken)

HRS Functional Support (Larry Henderson, Mike

Gollmar, Brad Bruegger, Rachel Holmquist)

DoIT Security (Stefan Wahe)

UW-TISC (Chris Liechty)

IAM Steering Committee (Elena Pokot) IAM TAG (Tom Jordan)

SFS (Julie Gordon)

Team Lead

Stefan Wahe

DoIT Security

Team Member John

Katolski

Ryan Leavitt

Application Support

Team Lead – HRS Service

Center

Derrian Jones

Team Member Jennifer

Hanewall-

Mamocha

Brad Krause

Cheryl

Sullivan

Colleen Kerl

Project Team

WiscIT

Team Lead-

Help Desk

Sean Bossinger

Team Member Chris

Grosspietsch (DoIT)

Diane

Blaskowski (SC)

Fatma

Demirbilek (SC) Brian Schildroth

(SC)

Purchasing

Kolleen Apelgren

Other Support

Training

Communic

ation

Testing

Integration Design

Team DoIT

Security IAM Support

Team (Ty Letto)

Vendor Project

Team

Other

End UserHRS Service Center and other potential common

system users

IAM

Team LeadTy Letto

Team Member Rachel

Wroblewski

Dan Spencer

Raji

Muthuraman

Jay Sundu

TBD

Project Manager (vendor)

Infrastructure SE

DRMT

NS/OP Eng

Middleware Vendor

HRS

Infrastructure

Vendor Business

Analyst

Developer

Vendor

4.2.2 Roles, Responsibilities The “Project Roles and Responsibilities” section of the project communication plan contains detail information for all project user roles and their responsibilities. The project communication plan is located at project’s wiki website: https://wiki.doit.wisc.edu/confluence/display/TBD 4.3 High-Level IAM Budget

Estimated $410,000.

https://wiki.doit.wisc.edu/confluence/display/SFAUTH/Communication+Plan

5. High-Level Control Strategies 5.1. Communications Strategy Effective and open communications is critical to the success of the project. The key communication objectives for the project are:

Promote and gain support for the OIM Upgrade;

Encourage use of project management best practices;

Give accurate and timely information about the project;

Ensure a consistent message. Use the following link to view a complete project communication plan. https://wiki.doit.wisc.edu/confluence/display/TBD 5.2 Quality Management Strategy for OIM Upgrade

1. Clear business requirements (Vendor, IAM Support Team) 2. Infrastructure Upgrade (Vendor, IAM Support Team) 3. User’s acceptance to the design prior to the development (DoIT Security

and Service Center) 4. User Testing prior to deployment (DoIT Security, vendor, and Service

Center) 5. Deployment Plan (IAM Team) 6. Clear Documentation (Lead Project Manager, Project Manager, DoIT

Security, HRS Training, Service Center) 7. Clear and Consistent Project Communications (Lead Project Manager,

Project Manager, HRS Communications, Service Center) 8. Training (HRS Training, vendor, DoIT Security, Service Center)

5.3 Issue Management Strategy The project team will work through project issues and decision points to the best of the ability of the team and in a timely manner. The project manager (vendor) will document these issues and decision points. See Communication Escalation Process and Communication Flowchart sections of the project Communication Plan (https://wiki.doit.wisc.edu/confluence/display/TBD) for detail process on how issues will be escalated throughout the life of the project. 5.4 Change Management Strategy for OIM Upgrade Broad and targeted communication techniques will be utilized to inform UW System service providers of the change in OIM, the impetus behind the change, and how it ultimately affects the system. HRS leadership and users must also be informed of the change and how it affects the HRS Core User experience.



The Communication Escalation Process section of the project communication plan (https://wiki.doit.wisc.edu/confluence/display/TBD) serves as a high-level change management process throughout the life cycle of the project. 5.5 Risk Management Strategy

Risk areas

1. The IAM system is limited to provision to a single instance of PeopleSoft. This means the current system cannot support provisioning to the HRS PeopleSoft instance and other PeopleSoft instances, such as Shared Financial System (SFS). As a result, failure to migrate to the new platform will result in multiple platforms being supported for two PeopleSoft systems increasing support and maintenance costs.

2. According to Oracle’s Lifetime Support Policy, OIM 9.1x goes to sustaining support in December 2013. This change in support equates to no new updates, security alerts, etc. The major risks of such a change in support are cost of extended support versus decreased support capability.

3. In the event that HRS does not migrate, the following opportunities are lost:

a. The general usability of the application has been greatly enhanced and provides a much more simplified self-service process. This enhancement alone will greatly reduce the amount of customizations that need to be made in order to upgrade the application. Taking advantage of these enhancements will reduce the number of customizations made to increase usability, which will reduce the time spent maintaining and extending these customizations. Because of the new shopping cart model for requesting access, users will need less training and will quickly find what they need

b. The ability to delegate the administration of artifacts to certain users based on their membership within an organization. This means certain administrative roles can be assigned to users to allow those users to manage which PeopleSoft roles are available to the campus. Using this feature, the IAM Support team and DoIT security can offload responsibility to a set of users without giving them full administrative privileges.

c. The current 10g extensions to the application are developed and deployed using a specialized and highly customized set of tools and scripts. In the new version, extensions are developed using a standardized toolset and the interfaces to the application are enhanced. These interfaces provide additional functionality and a


large portion of the code from the current system can be reused in the new system with minimal modifications.

d. The current IAM system is heavily customized to work directly with HRS limiting the system’s ability to handle requests for provisioning to other systems. That customization also takes additional developer time to support and maintain. By matching business and user processes to the way OIM is designed to work, Common Systems will reap the benefits of reduced maintenance overhead and more flexibility in integrating additional systems.

e. One of the key benefits to moving to the new version is the durability of updates. The process for developing extensions to the user interface has been improved in such a way that all extensions are applied on top of the vendor provided solution, rather than overwriting parts of the application. This means that these extensions will survive any patches applied to the software, saving costly development staff time and effort.

High-level risk management process

The core project team meets weekly. Any risks to the project will require a decision document. The decision document will describe the risk, alternatives, advantages and disadvantages as well as suggested solution. The Communication Flowchart and Communication Escalation Process sections of the Project Communication plan (https://wiki.doit.wisc.edu/confluence/display/TBD) serves as the high-level risk

management process throughout the lifecycle of the project.

Risk decision makers

The project sponsors (Lorie Docken, Elena Pokot, John Krogman), after careful consideration, will make decisions on major project direction and risk management strategies. The IAM Steering Committee (Elena Pokot) makes decision on technology-related risk management strategies. Unresolved issues will be elevated to the Administrative Systems Executive Committee as needed.

5.6 Procurement Strategy

1. Request for Services (RFS) a. Create an RFS to fill needed resources for this project.

i. Use accepted bid to create a fixed-price statement of work (SOW) for that particular vendor.


Multi-Factor Authentication Project Charter 11gR2 Upgrade Project Charter Page 1 Project Charter...

Documents

Transcript of Multi-Factor Authentication Project Charter 11gR2 Upgrade Project Charter Page 1 Project Charter...