Workday ATP TP_22_2789 Final 06302021.docx

Proposal No. TP-22-2789

UNIVERSITY OF WISCONSIN SYSTEM ADMINSTRATION

MADISON, WISCONSIN 53706

University of Wisconsin System Administration Office of Procurement 660 West Washington Avenue Suite 201 Madison, WI 53703

Todd Pooler

ISSUED DATE: 06/30/2021

DUE DATE: 08/06/2021 2:00 PM CST

Request For Proposal

THIS IS NOT AN ORDER

OFFICIAL SEALED

Proposal Number: TP-22-2789

NO PUBLIC OPENING

Issued Date: 06/30/2021

Due Date: 08/06/2020 2:00 PM CST Agent: Todd Pooler

Questions regarding this proposal – see Section 2.6

For Submittal Instructions & Proposal Response Format – see Section 2.2 and 2.3

Proposal prices and terms shall be firm for sixty (60) days from the date of the proposal to the opening, unless otherwise specified in this Request for Proposal by the UWSA Purchasing Services.

If NO BID (check here) ☐ and return.

Cloud-Based Enterprise Resource Planning (ERP) Systems Integration Services

In signing this bid, we have read and fully understand and agree to all terms, conditions and specifications and acknowledge that the UWSA Purchasing Services bid document on file shall be the controlling document for any resulting contract. We certify that we have not, either directly or indirectly, entered into any contract or participated in any collusion or otherwise taken any action in restraint of free competition; that no attempt has been made to induce any other person or firm to submit or not to submit a bid; that this bid has been independently arrived at without collusion with any other bidder, competitor or potential competitor; that this bid has not been knowingly disclosed prior to the opening of bids to any other bidder or competitor; that the stated statement is accurate under penalty of perjury. I certify that the information I have provided in this bid is true and I understand that any false, misleading or missing information may disqualify the bid.

By submitting a bid, the bidder certifies that no relationship exists between the bidder and the University that interferes with fair competition or is a Conflict of Interest, and no relationship exists between such bidder and another person or firm that constitutes a Conflict of Interest. Further, bidder certifies that no employee of the University whose duties relate to this request for bid assisted the bidder in preparing the bid in any way other than in his or her official capacity and scope of employment.

The Bidder certifies by submission of the bid that neither it nor its principals is presently debarred, suspended, proposed for debarment, declared ineligible, or voluntarily excluded from participation in this transaction by any federal department or agency.

Company Name:

Company Street Address:

Signature:

Type or Print Name:

Title:

Email address:

Table of Contents

1. General Information

1.1. Purpose:

The University of Wisconsin System Administration (UWSA) through its Purchasing Services Department, hereafter referred to as “Purchasing,” is requesting proposals for UWSA and all other institutions and administrative units of the University of Wisconsin System, hereafter referred to as the “University,” for Systems Integration (SI) Services to implement a cloud-based Enterprise Resource Planning (ERP) solution to succeed its current on-premise Enterprise Financial and Human Resources software.

The University will implement a cloud-based ERP solution from Workday. This cloud-based ERP solution (i.e., Workday) decision has been made and awarded on another contract. This solicitation is for SI Services only.

To successfully execute an implementation project of this scale and complexity, it is the intention of UWSA to award a contract to a single primary SI Services vendor who will work with the University on all implementation stages (defined as Planning, Design (Architect), Configure & Prototype, Test, and Deploy) and Post Go-Live Production support.

Background Since its creation, the University of Wisconsin System has established itself as one of the world’s premier public university systems. Each year the University educates approximately 170,000 students at 13 institutions and serves more than one million residents through statewide extension programs.

The University consists of two doctoral institutions (Madison, Milwaukee); eleven comprehensive institutions (Eau Claire, Green Bay, La Crosse, Oshkosh, Parkside, Platteville, River Falls, Stevens Point, Stout, Superior and Whitewater); 13 branch campuses; and a statewide extension network with offices in all seventy-two (72) Wisconsin counties. The University of Wisconsin System includes an administrative unit and a shared service unit. For more information about the University, visit: www.wisconsin.edu.

The University’s intent is to launch a single, integrated program, known as the Administrative Transformation Program (ATP) (www.atp.wisconsin.edu), a people, process, policy, and technology initiative which will work to right-size administrative complexity across the UW System to be supported by a modern cloud-based ERP solution.

The program includes implementation of the selected cloud-based ERP for Finance, Human Resources, and Research Administration. The business capabilities in scope for ATP are outlined in Appendix I.

ATP Vision, Mission, and Principles:

The overall objective of ATP is to right-size the administrative complexity to support the University’s missions of education, research, and outreach. Desired outcomes include intentionally designed and standardized end-to-end business processes, access to data for timely reporting and enhanced decision support, high quality process and technology experience for stakeholders, and a sustainable infrastructure which can respond nimbly to future opportunities and needs.

ATP aligns with the strategic direction set forth in the University’s 2020FWD, the priorities under the Commitment to Operational Excellence (CORE) initiative, the UW-Shared Services initiative, and its evolving information security programs and policies. It also addresses the technical and administrative shortcomings of the current state.

ATP Vision: Advancing the University of Wisconsin System’s mission by engaging staff and building an intuitive, intelligent, and innovative work environment.

ATP Mission: Engaging our communities to build a nimble Finance and HR environment that will transform how we work, providing access to data, standardizing business processes, and improving the user experience.

ATP Principles:

· Start with people, innovate together: We will learn from those who know best and design accordingly.

· Enable access to data: We will provide improved access to data and make it possible for our leaders to make more data-informed decisions.

· Simplify and streamline rigorously: We will clear the way for people to get their work done more efficiently.

· Just enough complexity: We will keep things simple with no more complexity than required.

· Design and build for the future: We will design nimble, sustainable, and resilient solutions.

· Make the right decisions in the right way: We are committed to making the right decisions by engaging our stakeholders and communicating regularly.

Current State The University currently uses Oracle/Peoplesoft software for its Shared Financial System (SFS) and its Human Resource System (HRS). These applications are hosted on-premises by University’s Division of Information Technology. SFS and HRS each have a single instance of Oracle/PeopleSoft supporting all institutions (institutions are represented as separate business units in the application). (See Appendix III: UW System Metrics for transactional information.)

The Shared Financial System (SFS) supports financial and research administration processes. SFS was first implemented in 1999 and an upgrade to Oracle/PeopleSoft version 9.2 was completed in 2018. A custom-developed data mart, WISDM/WISER, supports reporting and other local downstream systems. PeopleSoft modules in use include:

Accounts Payable Accounts Receivable Asset Management Billing Cash Management Contracts E-Procurement General Ledger Grants Procurement Card Project Costing Purchasing Travel and Expenses

The Human Resources System (HRS) provides personnel, payroll and benefits processing to all University institutions and employees. The system was first implemented in 2011 and an upgrade to Oracle/PeopleSoft version 9.2 was completed in 2017. A custom-developed data mart, EPM, supports reporting and other local downstream systems. Peoplesoft modules in use include:

Absence Management Benefits Administration Candidate Gateway/Talent Acquisition Manager Commitment Accounting eBenefits Human Resources Payroll for North America Performance Management Time and Labor The University has a variety of tools supporting reporting and analytic needs, including Oracle Business Intelligence Enterprise Edition (OBIEE), Tableau, Power BI, and other home-grown tools. OBIEE is supported at the enterprise level; the other solutions are provided and supported locally at the institutional level.

The University has identified over 650 ancillary and bolt-on information systems at UW-Madison and hundreds of additional systems across the UW System. Most ancillary and bolt-on systems are symptomatic of gaps in functionality of the current Shared Financial System (SFS) and Human Resources System (HRS), business process inefficiencies, challenges with data and reporting, gaps in training, and inconsistent policy interpretation.

The University’s landscape involves many enterprise level integrations, real-time synchronization of data and configuration elements between SFS and HRS, and several integrations with downstream systems. The University has a wide variety of bolt-on products and integrations that are in various stages within their product lifecycles. Some key bolt-on products and integrations include:

Plan UW: The University has implemented Oracle’s Planning & Budgeting Cloud Service (PBCS). The initial implementation project, which was completed in December 2018, included annual budgeting functionality with integrations to SFS and HRS. Subsequent implementation phases included multi-year forecasting and allocation. Roll-out of PBCS future functionality is on hold as ATP scope and timeline are further defined.

JAGGAER: The University has implemented JAGGAER’s One Source-to-Pay (S2P) cloud-based platform to replace and improve upon purchasing functionality. The planning for the project started in November 2019. There is a two-staged implementation plan with customer facing products implemented in Phase 1 in April 2021 and internal products planned to be implemented in Phase 2.

Student Information Systems: The thirteen institutions use Oracle/PeopleSoft’s Campus Solutions; each institution has its own instance of the software. There are integrations with SFS and HRS.

Research Administration: The University will be procuring and implementing a comprehensive software solution to streamline the pre-award Research Administration operations, and to provide post-award functionality that may not be provided by Workday. It is expected that such a solution will integrate with the future cloud-based ERP.

Interoperability: The Interoperability Initiative will establish improved integration and infrastructure services and practices across campus. The University has implemented Informatica Intelligent Cloud Services (IICS) to support improved connectivity between IT systems by enabling low/no-code integrations and data transformation. IICS provides out-of-the-box connectors that enable integration across myriad technologies and patterns, cloud/SaaS platforms, and technical modalities (e.g., file-, API-, message-based integrations, etc.). The University is currently in the process of implementing Google Apigee, an API management platform that will expose institutional and business unit-level APIs. Apigee will enable implementation of common policy/technical controls, aggregate the collection of available APIs in a common web interface, and reduce time-to-integrate by enabling integrators to test out APIs before gaining approval for production usage. This will be accompanied by establishing an API Program, a culture and ecosystem of API-based integration, across the University. Once complete, the implementation team will shift to developing APIs to common enterprise data domains (e.g., Identity/Person) to jumpstart the API Program. The University is in the process of implementing a product called midPoint for provisioning and deprovisioning and to manage user authorizations to applications. midPoint, along with its partner product Grouper, allows us to confer access to the right people, at the right time, to the right systems to enable the business of the University. The two other major areas of this initiative are improving user experience and privacy/security. These are actively being worked on in several different ways including using Salesforce to build out a one-stop user profile to be a single place for users to manage their identity information and preferences. See Appendix IV and Appendix V for additional information about current state technical architecture and integrations.

1.2. Scope of Work

1.2.1 Service Objectives

The high-level service objectives and benefits the University expects to receive by acquiring services from the selected SI Vendor include the following:

· Partnership and collaboration: University is seeking a vendor that will work closely with University personnel to co-create the optimal solution and facilitate the transfer of knowledge and expertise and work in partnership on professional and technical services provided to the program team (e.g., program and project management, business analysis, and technical consultation).

· Access to subject matter expertise: University is seeking a vendor with proven abilities in managing large-scale cloud-based ERP projects for higher education institutions; deep knowledge of higher education best practices across Finance, Human Resources, and Research Administration; experience in application of Artificial Intelligence, machine learning, robotic process automation and similar modern technologies; extensive experience reengineering business processes and workflows; strong capabilities in data cleansing and conversion from legacy systems to modern environments; demonstrated success in testing, validation, quality assurance and user acceptance; high degree of success in developing management approaches of cloud software release cycles; expertise in integration and interface development; and experience developing units that provide shared support services at scale.

· Timeliness of project delivery: University is seeking a vendor that can collaboratively drive the project forward effectively, complete project activities within agreed-upon time frames, and implement the solution in a timely manner to optimize organizational benefits.

· Quality, depth, and completeness of services: University is seeking a trusted and capable vendor partner that will skillfully manage and deliver a broad range of top-tier services that appropriately consider and address the needs of University’s complex environment.

· Change strategy support. University is seeking a partner with skills and experience in planning and delivering successful change management programs, including but not limited to stakeholder engagement and communications, development and delivery of training materials and courses, and change impact analysis and recommendations.

· Realization of organizational benefits across the university system: University is seeking a vendor that understands the University’s strategic goals for administrative transformation, can identify specific ways that ERP modernization will drive those outcomes, and will implement a solution that delivers desired benefits across all campuses and organizational units.

1.2.2 High-Level Scope Assumptions

Functional Scope The functional scope of this RFP includes organizational capabilities and use cases across Finance, Human Resources, and Research Administration. Proposers are advised to review the business process inventory in scope for ATP (Appendix I) and the Functional Use Scenarios (Appendix VI) to gain a full understanding of University’s scope that the selected SI Vendor’s implementation activities and deliverables are expected to encompass.

Key Integration Points and Coordination with Other Initiatives The functional scope for implementation activities and deliverables will also consider integrations with key legacy applications and third-party systems, which will involve coordination with other planned or in-process initiatives at University. For example, implementation activities and deliverables are expected to address integrations with Student Information Systems, Research Administration systems, procure-to-pay systems, and planning and budgeting solutions, among others. Proposers are advised to review Section 1.1 to gain understanding of University’s current-state system environment and future-state direction.

Proposed Timeline Based on information and analysis completed during the preplanning and prepare stage of ATP, the University developed a tentative implementation schedule. The schedule is subject to adjustment based on the Planning and Design (Architect) Phases.

* note that calendar quarters are represented, not fiscal quarters.

1.2.3 Services Overview

Planning Services Overview Planning Services are intended to ensure alignment on project scope, governance, roles and responsibilities, plans, resources, dependencies, and other standard program components required for collaboration and alignment between University and the selected SI Vendor. In addition, Planning Services will produce specific Deliverables that are prerequisites for an effective and efficient Design (Architect) stage.

At a minimum, University expects that Planning Services will include the following activities and deliverables. As noted below, ATP has started or partially completed many Planning activities and deliverables listed in the preplanning and prepare stages. Proposers may also recommend additional activities and deliverables that are in alignment with their proposed approaches and best practices.

Planning Activities:

Scope planning (partially completed) Schedule planning (started) Resource planning (started) Budget planning (partially completed) Overall approach to project planning (started) Overall approach to business process design and configuration Project-related team formation (started) Project governance planning (started) Review of ancillary technology environment (e.g., third-party systems, bolt-on systems) (partially completed) Integration and interface planning Data conversion planning Reporting and analytics planning Operational model planning (e.g., future-state departmental structures, roles) Future state support model (partially completed) Security planning Benefits realization planning (partially completed) Learning and development planning (partially completed) Deployment and rollout planning Review of proposed Chart of Accounts (COA) and FDM/COA mapping design Change management planning (partially completed) Communication planning (started) Project process improvement plan Quality management plan Stakeholder management plan

Planning Deliverables:

Finalized project scope, cost, and schedule baseline Detailed project and implementation plan (e.g., in-depth timeline encompassing all activities, deliverables, milestones, rollouts, resources, etc.)

Funding model/Total Cost of Ownership Data/reporting/analytics strategy Inventory of ancillary technology and preliminary recommendations on disposition Data conversion strategy Integrations and interfaces strategy User Experience Strategy Workflow and document management strategy Tenant Migration/Release Management Strategy Implementation team formation Finalized governance structure Support team and continuous improvement team formation Future-state operational model Benefits realization metrics and baselines Approach to business process mapping, design and configuration Security strategy Learning and development strategy Finalized COA structure/ Foundation Data Model (FDM) Design Change management plan Communication Plan Project risk register and plan

Design (Architect) Services Overview Design (Architect) Activities are intended to produce Design (Architect) Deliverables that define and specify in detail the optimal solution for University. University expects the selected SI Vendor to design a solution that delivers high value across all domain areas and campus locations while maintaining manageable levels of cost and complexity.

At a minimum, Design (Architect) Services will include the following activities and deliverables. Proposers may also recommend additional activities and deliverables in their RFP Responses that are in alignment with their proposed approaches and best practices.

Design (Architect) Activities:

Develop guiding principles for solution design Design analysis and requirements development Process and workflow design (i.e., business process reengineering) Reporting and analytics design Further analysis of ancillary technology Data conversion design Integration and interface design, including system dependencies Learning and development design Training for ATP team Security design Current-state policy analysis and future-state policy design Organizational change management design (business and IT) Testing planning and design Analysis of change impacts Benefits realization analysis

Design (Architect) Deliverables:

Guiding principles for solution design Design (Architect) analysis results (e.g., any functional requirements that cannot be met by the selected software solution) and associated recommendations Future-state business process maps for all processes in scope Initial reporting and analytics specifications Inventory and final recommendations for disposition of ancillary technology, including governance approach for any future ancillary technology Finalized data conversion specifications Integration and interface requirements Learning objectives and training requirements Training delivered to UW’s project team (i.e. functional and technical) Security profile requirements Change inventory, impacts analysis, and initial organization change management recommendations Organizational hierarchy requirements End-to-end process testing scripts Policy change documentation and impact analysis Initial benefits realization design and quantified estimates of opportunities

Configure & Prototype Services Overview Configure & Prototype Services include configuration of the selected software solution based on the specifications set forth in the Design (Architect) stage. Data conversion preparation activities and the development of integrations and interfaces to other systems are also part of Configure & Prototype Services. Developing and finalizing the details of the learning and development approach and curriculum, and related reference materials will also occur during the Configure & Prototype stage.

High-level guidance related to these services is provided below. Proposers may also recommend additional activities and deliverables that are in alignment with their proposed approaches and best practices.

Configuration Services provided by the selected SI Vendor will enable University to leverage the software solution’s built-in functionality and to implement best practices. Configurations implemented during this project stage will provide both standardization and flexibility to meet common and unique needs across all University institutions and organizational units. Configuration Services will include the configuration of in-scope business processes, forms, workflow, organizational structures, alerts/notifications, reporting and analytics, role-based security, and other business rules and system logic. It is critical that configurations are implemented in collaboration with University leads and SMEs, so knowledge transfer occurs naturally throughout the process.

Data Conversion preparation services provide the foundation for subsequent implementation activities that will enable University to access and leverage business-critical data that originated in legacy systems and/or third-party systems retained by University.

Integration/Interface Development Services will also provide the foundation for University to share business-critical data from the selected software solution with third-party systems retained by University.

Testing Services will provide the build of testing environment, implementation of any automated testing tools, and build of test scripts.

Training Development Services provided by the selected SI Vendor will focus on both business and IT stakeholders. These services will include supporting the University’s Change Strategy team in the creation and refinement of a detailed training curriculum, which will incorporate end-to-end process training and software usage training. Services will also include the development of reference materials and support documentation like user manuals, FAQs, process maps, and policy guides.

Test Services Overview Test Services will focus on testing and refining the solution that was configured and developed during the Configure & Prototype stage.

High-level guidance related to these services is provided below. Proposers may also recommend additional activities and deliverables that are in alignment with their proposed approaches and best practices.

Test Services are expected to include multiple business process test cycles, system testing, integration testing, parallel payroll testing, mock migration testing, performance testing, security testing, and user acceptance testing (UAT). Based on the results of these tests, the selected SI Vendor will make recommendations to University regarding adjustments to the system configurations, integrations, and data conversions that were previously developed. The Services will also include activities to validate that the solution meets or exceeds Benefits Realization expectations and to implement a continuous improvement program.

Deploy Services Overview Deploy Services encompass the delivery of training to all University users and the final deployment of the solution as tested and refined during the Test stage, including final conversions and final cutover for all campus locations.

High-level guidance related to these services is provided below. Proposers may also recommend additional activities and deliverables that are in alignment with their proposed approaches and best practices.

Training Delivery Services include supporting the University’s Change Strategy team in the delivering of end-user training to both business and IT stakeholders. End-user training courses may include end-to-end process training and software usage training in an integrated fashion and will be delivered prior to rollout/cutover for all required sites. Training Delivery Services will also include finalizing and distributing reference materials and support documentation such as user manuals, FAQs, process maps, and policy guides.

Deployment Services focus on final preparation and rollout at each campus location and within the support organization, from pre-cutover through cutover. These services include enabling operational readiness at each rollout site (e.g., ensuring that all policy, process, and organizational changes and impacts are understood); implementing the future-state support model and enabling IT/ERP support team readiness; ensuring site data readiness; completing final data conversions; ensuring supplier, customer, and third-party partner readiness; and deploying final integrations/interfaces.

Post Go-Live Production Support Services Overview Post Go-Live Production Support Services refer to the range of post-cutover support services that the selected SI Vendor will provide to University throughout an agreed upon warranty period. Immediately after the Deploy stage and deployment, Post Go-Live Production Support Services may include activities like documenting, tracking, and resolving issues related to the implemented solution; measuring end-user satisfaction and recommending solution improvements or additional change management activities required; measuring and optimizing system performance; and facilitating a seamless transition of support to the longer-term University support team and/or any third-party partners who will provide longer-term support on behalf of University. Alternatively, vendors may propose optional longer-term Post Go-Live Production Support Services such as ongoing help desk management, release management impact analysis, and configuration/enhancement management.

1.2.4 Planning and Design (Architect) Services: Additional Guidance The tables set forth below identify expected roles and responsibilities associated with Planning and Design (Architect) Services for both the selected SI Vendor and University personnel. Please note that the contents of these tables are not intended to be fully exhaustive, and they are not inflexible; roles and responsibilities may be added, removed, or adjusted over time to reflect the evolving project context and approach. However, University advises Proposers to consider these high-level guidelines when developing their RFP Responses.

For each identified Planning activity, an “X” has been placed in the column under the party that University expects will be responsible for performing the task. Responsibilities of the selected SI Vendor are indicated in the column labeled “Vendor,” and University responsibilities (including responsibilities of University-contracted third parties) are indicated in the column labeled University. For tasks that are indicated as the selected SI Vendor’s responsibility, it is assumed that University staff will participate where needed based on the selected SI Vendor’s direction—and it is also assumed that most Planning activities will require close collaboration between the selected SI Vendor and University.

TABLE 1. Planning Roles and Responsibilities

Determine and communicate the organizational capabilities, high-level business processes/use cases, technologies, organizational units, and campus locations that are in scope for the project

X

Determine and communicate related initiatives that are planned or in-progress and potentially affect the project

X

Define the scope to a greater level of detail and document the refined scope via a formal project scope/charter

X

Review, refine, and approve the refined project scope/charter

X

Determine and communicate the availability of key University roles/resources (e.g., Project Manager, OCM Lead, Subject Matter Experts, etc.) to be engaged over the course of the project

X

Review, refine, and approve the proposed resource plan, including team and governance structures

X

Communicate the high-level roadmap and rationale for project phasing and rollout timing, including any known dependencies and risks

X

Communicate any mandated milestones, blackout periods, and other schedule assumptions or constraints

X

Review, refine, and approve the proposed project plan

X

Review, refine, and approve the integration strategy and roadmap

X

Review, refine, and approve the data cleansing and migration strategy and roadmap

X

Educate Vendor on University stakeholder context across business and IT, highlighting current state pain points, future state benefit expectations, and areas with particularly high change impact expected

X

Review, refine, and approve the strategy and roadmap for business process design

X

Review, refine, and approve the security strategy

X

Review, refine, and approve the data, reporting, and analytics strategy

X

Review, refine, and approve the test strategy

X

Review, refine, and approve the learning and development strategy and roadmap

X

Review, refine, and approve the high-level communications plan

X

Review, refine, and approve FDM structure and mapping.

X

TABLE 2. Design (Architect) Phase Roles and Responsibilities

Design (Architect) Analysis

Provide access to business and IT process owners, leads, and subject matter experts

X

Attend and participate in design workshops

X

Review, refine, and approve Design (Architect) analysis deliverables and recommendations

X

Review, refine, and approve key decisions

X

Review, refine, and approve updated functional and technical requirements

X

Core Design (Architect)

Provide business process owners, leads, and SMEs to work collaboratively with the Vendor in all design activities to ensure University’s organizational context and impacts are considered throughout Design (Architect) stage

X

Provide IT process owners, leads, and SMEs to work collaboratively with the Vendor in all design activities to ensure that IT context and impacts are considered throughout the Design (Architect) stage (e.g., data, security, infrastructure, integration, support, etc.)

X

Review, refine, and approve inventories, baseline configuration design, and change impact documentation

X

Review, refine, and approve specifications

X

Review, refine, and approve prototypes, if applicable

X

Review, refine, and approve Configure & Prototype estimates

X

Data Migration Design

Review, refine, and approve data migration design deliverables

X

Reporting and Analytics Design

Review, refine, and approve reporting and analytics design deliverables

X

Integration Design

Review, refine, and approve integration design deliverables

X

Security Design

Review, refine, and approve security design deliverables

X

Test Planning

Provide a University IT Lead and IT SMEs to work collaboratively with the Vendor

X

Review, refine, and approve testing planning and design deliverables

X

Change Strategy Design Change strategy is a workstream that begins during the Planning and Design (Architect) stages and continues through Configure & Prototype, Test, Deploy and Post Go-Live Production Support stages. The information provided in this section deals only with the up-front Change Strategy activities for the Design (Architect) stage.

The University expects that the selected SI Vendor will, in collaboration with University personnel, utilize a proven methodology and associated tools to deliver Change Strategy services aligned with University’s project scope, key strategic themes/organizational drivers, and priorities. University also expects the selected SI Vendor to apply its industry, process, and solution-specific expertise to minimize downstream re-work and promote engagement, alignment, and buy-in from University business and IT stakeholders throughout the project lifecycle.

TABLE 3. Change Strategy Design (Architect) Roles and Responsibilities

Process/Role/Organization Change Design (Architect)

Provide a University Change Strategy lead, business process owners, and SMEs to work collaboratively with the Vendor in all design activities to ensure University organizational context and impacts are considered throughout the Change Strategy design

X

Review, refine, and approve (or reject) change recommendations

X

Review, refine, and approve all Change Strategy design deliverables

X

Communications Design

Provide a University Change Strategy Lead and communications resources to work collaboratively with the Vendor

X

Review, refine, and approve communications design deliverables

X

Training Design

Provide a University Learning and Development Lead and business process SMEs to work collaboratively with the Vendor

X

Review, refine, and approve training design deliverables

X

IT Operating Model Change and Deploy Design

Provide a University IT Lead and IT process SMEs to work collaboratively with the Vendor

X

Review, refine, and approve (or reject) change recommendations

X