phase ii project plan v3.2 - web presence program · angela thalls humanities migration lead ......

Web Content Management System (WCMS) Phase II Implementation Plan Information Technology Services and University Relations

11/9/2009 v.3.2 – Final Author: Leslie Geary

UC Santa CruzWeb Content Management System (WCMS) Phase II Implementation Plan ii

Document Control

Change Record

Date Author Version Change Reference

8/20/09 Leslie Geary 1.0 Start

9/14/09 Leslie Geary 1.1 Incorporate feedback from Mark Cianca Incorporate feedback from David Turner Additional edits/content added Sent to Team Leads for review 9/21

9/22 Leslie Geary 1.2 Changes to staffing mostly – sent that section out for team lead review. Sent to Sue Roth.

9/24 Leslie Geary 1.3 Incorporate comments from David T., Andrea Additional changes to staffing section

10/1/09 Leslie Geary 1.4 Incorporate comments from Charles McIntyre and update timeline

10/7/09 Leslie Geary 2.0 Incorporates feedback from Mark Cianca. Ready for sponsor review and sign-off pending decision to move forward.

10/22/09 Leslie Geary 3.1 Incorporates feedback from David Turner. Ready for sponsor review and sign-off.

11/9/09 Leslie Geary 3.2 Few minor edits by Mark.

Reviewers

Sign Off Date Reviewer Position Sign Off David Turner Web Program Mgr.

Mark Cianca WCMS Co-Sponsor

Barry Shiller WCMS Co-Sponsor

Charles McIntyre Technical Team Lead

David Rosen Technical Team Lead

Rob Knight UR Migration Lead

Angela Thalls Humanities Migration Lead

Andrea Hesse Humanities Migration Co-Lead

Sue Roth Porter Migration Lead

UC Santa CruzWeb Content Management System (WCMS) Phase II Implementation Plan iii

Table of Contents

DOCUMENT CONTROL ...........................................................................................................................II Change Record........................................................................................................................................................ ii Reviewers ii

TABLE OF CONTENTS...........................................................................................................................III

1 EXECUTIVE SUMMARY....................................................................................................................1 1.1 Introduction.................................................................................................................................................. 1

1.1.1 Purpose ................................................................................................................................... 1 1.2 High Level Plan: Procurement, Installation and Site Migrations ................................................................ 1 1.3 Risks and Dependencies .............................................................................................................................. 2

1.3.1 Risks ........................................................................................................................................ 2 1.3.2 Dependencies .......................................................................................................................... 2

1.4 Primary Project Staffing .............................................................................................................................. 3

2 PHASE II OBJECTIVES AND SCOPE ..............................................................................................4 2.1 Objectives .................................................................................................................................................... 4 2.2 Phase II Deliverables ................................................................................................................................... 4 2.3 Scope Elements TBD................................................................................................................................... 6 2.4 Out of Scope ................................................................................................................................................ 6

3 PROJECT PLAN ................................................................................................................................7 3.1 Implementation and Roll-out Strategy......................................................................................................... 7 3.2 Implementation and Roll-out Plan ............................................................................................................... 7 3.3 Implementation Work Package Description ................................................................................................ 9

3.3.1 Procurement............................................................................................................................ 9 3.3.2 System design and installation................................................................................................ 9 3.3.3 Functional Requirements, Configuration, & Development .................................................... 9 3.3.4 Site Migrations and Standard Migration Process .................................................................. 9 3.3.5 Deployment Management ..................................................................................................... 10 3.3.6 Documentation and Communication .................................................................................... 10

3.4 Communication Plan.................................................................................................................................. 10 3.4.1 Official Communication........................................................................................................ 10 3.4.2 Status Reports ....................................................................................................................... 10 3.4.3 WCMS Web Site .................................................................................................................... 11 3.4.4 Migration Partners ............................................................................................................... 11 3.4.5 ITS Stakeholders ................................................................................................................... 11

UC Santa CruzWeb Content Management System (WCMS) Phase II Implementation Plan iv

3.4.6 End of Project ....................................................................................................................... 11 3.5 Success Criteria.......................................................................................................................................... 11 3.6 Issues and Policy Implications................................................................................................................... 11 3.7 Risk Management Plan .............................................................................................................................. 12

4 TECHNICAL REQUIREMENTS .......................................................................................................14

5 PROJECT ORGANIZATION AND STAFFING.................................................................................15 5.1 Staffing Chart............................................................................................................................................. 16 5.2 Roles and Responsibilities ......................................................................................................................... 16

6 BUDGET...........................................................................................................................................22

Web Content Management System (WCMS) Phase II Implementation Plan 1

1 Executive Summary

1.1 Introduction

1.1.1 Purpose This document serves as a change request to the WCMS Charter approved in September 2008. It supersedes the previous high-level implementation plan submitted in February 2009. It refines the project plan and does not alter the scope or deliverables previously approved.

1.2 High Level Plan: Procurement, Installation and Site Migrations

The work to be completed in Phase II of the project encompasses six distinct although highly interdependent work packages.

• Procurement (underway as of Sept. 2009)

• System Design and Installation (beginning as of Sept. 2009)

• Functional Requirements, Configuration, and Development

• Site Migrations and Standard Migration Process

• Deployment Management

• Documentation and Communication

Once the system has been purchased, installed, configured, customized and the standard migration process can be tested, actual site migrations can begin. At least three migrations are planned.

• UCSC Home Page environment (produced by University Relations)

• Humanities division site and two departments

• Porter College

All migration partners have completed initial assessments of migration scope, feasibility, interest, and commitment. There is a high degree of interest and commitment from all partners.

ITS is a backup migration partner in the event another partner is unable to move forward.


1.3 Risks and Dependencies

1.3.1 Risks • Resources: Staff resource capacity could introduce significant risk in terms

of duration and quality. An added factor is the current furlough program and the reduced capacity it introduces.

• Business Requirements: Course information requirements may prove too complex to include in scope, which will have negative repercussions for successful Humanities migration in addition to post-project migrations.

• Out of Scope Business Requirements: local design, content editing, and new department level information architecture are out of scope for the WCMS project but are important business functions that are largely missing on campus. Although the Web Function and Design project will provide designs for departmental templates, there are no campus-wide resources to provide design services to provide local distinction inside the template.

• Scope: From a preliminary analysis, it appears that some sites have an enormous number of files. The lack of campus intranet and document/digital asset management systems may impose a huge burden on WCMS migrations.

• Technology: Off site failover solution may fail to meet disaster recovery expectations.

• Technology: Coding on pages by non-ITS staff may introduce risk to web server making policies around release important if the activity is allowed.

• Service: Service ownership for enterprise applications is typically a business side function. Service ownership by ITS will add functional training and support to our services which are not typically an IT function.

• Roles and responsibilities: web service providers include University Relations, the Infrastructure and Tools Team (ITS), and the Web Applications Team (ITS). A new concept of services and service provision may lead to some ambiguity of roles and responsibilities. Work to help clarify and define roles and responsibilities, both the in the context of the project and during operations, will be required.

1.3.2 Dependencies The dependencies below introduce risk that must be mitigated and, therefore, are included in the Risk Management Plan, Section 5.7.

• Migration Partners: Successful migrations depend upon migration partner availability and commitment.

• Other Web Program Components

o Web Function and Design Project: template design and information architecture deliverables have many functional and schedule-related interdependencies.

o Web Service Definition Project will derive information from WCMS as a result of practical migration experience and the WCMS


project will require the Service Definition project to provide direction.

o Web Governance: The WCMS project will rely upon Web Governance to develop policy where needed for implementation or operations.

• Web Presence Program Funding: As of this writing, the budget for infrastructure and operational staffing for WCMS has not yet been committed by the campus. In a time of financial stress this increases the risk of insufficient operational resources to meet campus needs and expectations. The project recommends obtaining firm commitment of campus resources to cover infrastructure and operational staff prior to execution.

1.4 Primary Project Staffing

Web Program Executive Sponsors – Mary Doyle and Donna Murphy Project Sponsors - Mark Cianca and Barry Shiller Web Program Manager – David Turner Project Manager – Leslie Geary Technical Leads – Charles McIntyre, David Rosen Migration Leads – Andrea Hesse, Rob Knight, Sue Roth, Angela Thalls Team subject matter experts – Marion Bashista, Andre Daniels, Jacques

Delsemme, Tom Gardner, Teresa Silva, Galen Sullivan


2 Phase II Objectives and Scope

2.1 Objectives The objectives of Phase 2 remain consistent with the original scope:

• Procure and install the selected web content management system

• Plan, test and deploy initial information architecture framework and update, document or leverage from existing

o Templates

o Workflows for known sites to be migrated

o Roles and responsibilities

o Content guidelines

o Support and training materials

o Services to be provided

o System schematic - logical and physical design

• Plan, test and execute phased site migrations

2.2 Phase II Deliverables Phase 2 Project Deliverables by Work Package

Work Products/Description

Procurement: Executed vendor contract Contract review Contract negotiation Award Purchase

System Design and Installation Approved and installed application environment

Technical architecture design Approval from Design Review Board (DRB) Define project technical roles to fit ITS reorganization Application installation and technical configuration IDM integration for user authentication Business continuity/disaster recovery requirements, option feasibility, and implementation Technical training Document roles/resp for initial operations Technical documentation Present tech design to DRB


Functional Requirements, Configuration, and Development –

• Approved functional design • Application configured, tested, and

documented to meet business needs

• Development completed, tested and documented to meet business needs.

Application configuration plan to meet business needs (directory structure, role & group definitions, logical organization of components, etc.) Development of application components (templates, forms, workflows, etc.) Configuration testing plan Successful completion of the configuration and testing plan Document configurations Develop script specifications for structured content migration for tech team Development/programming (if required) Integrate with external systems (if required) Test/QA of scripts/development/integration Develop technical documentation for developed solutions Assess ramifications to web layer of “pass through code” and develop policy as appropriate Present any functional design to DRB if required

Site Migrations and Standard Migration Process

• In-scope sites migrated • Site end-users trained • Standard migration process

documented • Migration priority criteria

recommended

Engage and manage migration partners and stakeholders Develop site migration plans Manage partner preparations (purging content, etc.) Oversee static content migration Stakeholder review/approval Help partners define roles and responsibilities Develop user training materials Conduct user training Develop migration test plan Execute migration test plan Define a high level standard site migration process and lessons learned to hand off to operations Recommend migration priority criteria to Web Governance. Present any migration planning to DRB if required.

Deployment Management • Successful go-live (technology,

functionality, migration, training etc.)

Create deployment plan and manage deployment This will involve developing a deployment checklist and oversight to assure that all elements are complete prior to deployment. Present deployment plan to DRB Change/release management

Documentation and Communication

• Documentation is organized • Project web site kept up to date • Regular stakeholder status

completed • Out-of-scope requirements

documented. • Stakeholder presentations complete

Work with each sub team to develop and organize documentation, including:

• Technical • Technical training • Application Configuration • Testing plans • User training

Document requirements not met by WCMS deliverables Web Presence and Services Program Team or the Web Council as input for future deployment strategies. Web communication


Status Reporting and stakeholder presentations Other public communication as needed

2.3 Scope Elements TBD Several elements lack sufficient clarity without further analysis to determine whether they are in or out of scope:

• Number and scope of site migration: the number of Humanities departments that can be accommodated within the project is unknown. The scope of the University Relations migration is not fully defined.

• Use of authoritative course information is currently available using the “template system” and some academic departments expect this functionality. Whether it is in scope for Phase II is dependent upon analysis of complexities involved.

• Fully redundant off-site disaster recovery of editing and publishing functionality may prove too complex and costly.

2.4 Out of Scope Other deliverables that are out of scope for the WCMS Project include:

• Creation of strategic and implementation plans for campus response to web security and policy/regulatory compliance beyond Design Review Board process.

• Web standards work for development and integration (with the exception of standards and release policy for code passed via system to web layer.)

• Full or extensive evaluation and mitigation for compliance and accessibility issues

• Definition and implementation of a campus communication strategy as it relates to operational web services

• Extensive service definition of the new web services to be deployed

• Retirement/repurpose of existing web content delivery infrastructures

• Integration with external systems such as AIS, FIS, Calendar, LMS/CLE, etc.

• Design/revision of new campus template “Look and Feel”

• Resolution of funding source for hiring of operational staff.


3 Project Plan

This section of the document presents a high-level project plan. It does not include a detailed plan with all resources, work units or assignments. Detailed work packages of this high-level plan will be tracked separately and shared as appropriate by the project manager with the teams within the project.

3.1 Implementation and Roll-out Strategy The strategy to implement the new centrally supported WCMS and roll out a standard site migration process includes the following work elements.

• Procurement – negotiate a contract with the vendor and complete the purchase of the application.

• System Design and Installation – design and installation of hardware, software, and process components supporting the application environment

• Requirements, Configuration, and Development – requirements elicitation, configuration and development of the application to meet user requirements

• Site Migrations and Standard Migration Process – migrate 3 or more sites into the WCMS, train users, and develop a high level standard migration process based on lessons learned during project migrations.

• Deployment Management – create a deployment plan for release of infrastructure, configurations, development projects, and migrations and assure release readiness.

• Documentation and Communication – collect and organize documentation and project communication

3.2 Implementation and Roll-out Plan The high-level timeline follows for implementation and rollout. [A key weakness in estimating dates is the current unknown availability date of the vendor. Here we assume availability to develop SOW as soon as the contract is finalized.]

Assumptions for the following timeline include: Contract negotiations are successful Actual award is not delayed after successful negotiations Vendor can engage as soon as contract negotiations are complete Two weeks off over winter break and one week over Thanksgiving break Availability of other team resources as specified below Twenty percent reduction in capacity due to furloughs and staff loss


Key unknowns include vendor availability, complexity of migrations, and lack of disaster recovery design precedent at UCSC.

Work Package Name Duration Estimated Start

Estimated End

Final approval to purchase 0 day Sept 4 Nov 6

System and Application Implementation

Design prod, stage, dev technical architecture

14 weeks Sept 10 Dec 18

Research and determine disaster recovery strategy and finalize agreement.

13 weeks Jan 4 April 2

Negotiate, procure and receive application (in progress)

11 weeks Sept 8 Nov 20

Engage vendor / develop SOW* 3 weeks Dec 1 Dec 18

Technical training* 3 week Jan 11 Jan 28

Install dev tech config 4 weeks Oct 19 Nov 20

Functional config. requirements, development requirements and specifications

15 weeks Oct 26 Feb 26

Development 14 weeks Jan 11 April 16

DRB archictechture approvals 3 weeks Jan 4 Jan 21

Final production infrastructure complete (prod, stage, dev)

8 weeks Jan 25 March 19

Disaster recovery infrastructure in place and tested

10 weeks April 5 June 11

Site Migrations and Closure

Mock testing migrations 4 weeks March 8 April 9

Final development, configuration, and test

4 weeks April 12 May 7

Ready for site migrations? 0 day May 10 May 10

Site migration – UR 8 weeks May 10 July 9

Site migration - Humanities 8 weeks May 10 July 9

Site migration - Porter College/administrative site?

4 weeks June 7 July 9

Finalize docs and training 2 weeks July 12 July 23

Close WCMS – Stakeholder review, move to operations

3 weeks July 26 Aug 13


3.3 Implementation Work Package Description

3.3.1 Procurement Procurement and Business Contracts will procure software, consultation time, and three-year support contract from the selected vendor.

3.3.2 System design and installation The technical aspects of the system implementation will be conducted by a core technical team including two ITS team leads, PM, and rotating technical experts depending upon work products (programming, security, server admin, network, architects, IDM manager, etc.)

Disaster recovery is a deliverable of this workgroup. Requirements will be gathered, options reviewed, and feasible option implemented. Because no precedent at UCSC for off-site disaster recovery is available, the options will be researched and analyzed for feasibility. The lack of precedent will be verified.

Specific deliverables are listed in section 4.2.

3.3.3 Functional Requirements, Configuration, & Development Logical configuration of the application to meet business needs will include developing knowledge of the application function as well as the partner business requirements. Also key will be engagement with the vendor to understand best practices.

Unlike technical configuration, functional configuration includes definition of business requirements related elements such as users/roles/groups, workflows, and user interface configurations. Hannon Hill Cascade Server has components that combine templates, configuration settings, and user groups together. A logical analysis of the best configuration is critical to maintaining scalability and functionality.

This configuration team will engage and include technical team members and migration team members in developing requirements and specifications for configuration and development.

To the extent required to meet project deliverables, the team will gather business requirements, create specifications, and develop scripts, API interfaces, external application integration.

Specific deliverables are listed in section 4.2.

3.3.4 Site Migrations and Standard Migration Process The site migration team will work closely with migration partners to plan, execute, and test site migrations and will also work with the configuration and technical teams to assure requirements are understood and configurations, integrations and scripts are understood and tested. They will assist the partner in testing migrations. This team will involve partner-side analysts or power users.

The site migration team will also identify and engage site governance to vet plans and approve deployment. In addition, the site migration team will help partners define roles and responsibilities.


The site migration team will also develop a high-level site migration process and lessons learned document to hand off to operations.

3.3.5 Deployment Management A core team including team leads will be responsible for deployment planning, will develop a checklist of activities and tests that must be performed prior to deployment, and will be accountable for their successful completion prior to deployment.

3.3.6 Documentation and Communication This team will be responsible for assuring that documentation to be handed off to the service team is created by the appropriate sub-teams and is stored/organized in the appropriate place prior to project close. This includes:

• Technical documentation

• Technical training materials

• Application configuration

• User training materials

• Requirements not met by WCMS

The team will also be responsible for updates to the web site and other public communications as needed.

3.4 Communication Plan Engaging the campus in the WCMS project through the Web Presence and Services Program Team or Web Steering Committee is critical to its eventual adoption and success.

3.4.1 Official Communication At the outset of Phase II, a brief official communication will be sent on behalf of the Executive Sponsors Doyle and Murphy to all stakeholders announcing official start of new phase and setting expectations.

Phase II kickoff meeting with project teams and business stakeholders with Web Leadership in attendance to generate renewed energy and set expectations.

A campus-wide communication from the EVC is recommended near the end of Phase II.

3.4.2 Status Reports Status reports will be sent out and posted to the web site monthly and will include additional stakeholders:

New technical stakeholders include new team members, technical subject experts, managers of new team members and technical subject area experts (for example: Greg Gaither, Gary Moro, Steve Zenone.)

New business stakeholders will include migration partner staff and management.


3.4.3 WCMS Web Site The WCMS web site will continue to be updated with status, news, project plan, change requests, etc.

3.4.4 Migration Partners Led by the migration team leads, migration partners including management and key staff will be engaged early on and on a regular basis to identify priorities and issues, assure local resource participation, and make sure expectations are clear.

3.4.5 ITS Stakeholders • SMT

• APMMG

• DL Council meeting attendance as their schedule permits

• Web Coords meetings

3.4.6 End of Project End of project communication will include

• Presentation to governance bodies

• Project closure summary report with operational information to stakeholders

End of project communications may include

• Town hall style presentations to campus

• Campus-wide communication from Chancellor

3.5 Success Criteria • A central WCMS is implemented and accepted by primary stakeholders

including academic and academic support web site migration participants

• Clear roles and responsibilities are established for content creation, maintenance, and the support of the technology

• In-scope web sites are migrated to the content management system

• Campus stakeholders are kept informed of developments and are provided with opportunities to comment and participate

3.6 Issues and Policy Implications Policy issues or standards that must be considered or addressed by the Web Presence and Services Program, Web Steering, and the Web Council are:

• Governance practices


• Design and branding

• Web policy and standards

• Workflow processes/policies

• Service management / service definition

o Service manager – role must be filled to lead the service team

o Service team – collaborative cross-campus team to manage day-to-day support and delivery of the web content services

o OLA – shared operational procedures for support and delivery of web services

o SLA – shared service levels for service delivery and performance

o Costing model – equitably deliver web services to entire campus community and ensure an appropriate division of shared costs

3.7 Risk Management Plan Some dependencies introduce significant risk and are therefore included in the plan.

Risk Factor Probability

(H-M-L) Impact (H-M-L)

Risk Management Action

Insufficient operational staff are on hand to continue support and migrations due to inadequate or unresolved funding. Impact to project is mostly perception of project success.

H H Web Leadership continuing to work with campus to identify funding as well as plans for staff hiring or reassignment to support Web Services.

Dissatisfaction with limited functionality of WCMS – scope creep. Potential impact on project progress as well as success in encouraging participation and eventual adoption

M H Phase 2 will document potential future projects to meet needs as well as needs that are not appropriately met by a WCMS system (document management, etc.)

Division/department staff do not follow through on site prep and content migration due to bandwidth or conflict with academic calendar, etc.

M H Migration team will include client-side members and will work closely with other client-side staff to plan the work appropriately and manage activities. In all cases, management has identified this work as a high priority and can reinforce follow through.

Course information requirements identified by the academic departments may involve complexities that may exclude this requirement from scope.

M M Clearly analyze requirements and technical feasibility. Early communication with stakeholders.

Resource commitments will continue to be a risk especially as furlough days are taken.

M M Clear commitment of adequate resources required. Plan incorporates reduction in capacity due to furloughs. Project needs will be prioritized as furlough day requests are processed.


Web Function and Design project template and IA deliverables delay WCMS

M M Program and project manager will make sure to monitor progress and will work with Rolling Orange and Hannon Hill to predict potential problems.

Frustration due to selection of product may negatively impact motivation and public perception and therefore impede progress.

M M Clear communications from project leadership and from project staff.

Off-site failover solution fails to meet expected disaster recovery needs.

M M Off-site disaster recovery of key campus web pages or sites should not present a problem. Full redundancy may end up being a far more complicated matter. The project will research this and work with leadership to assure expectations are in line with feasible solutions.

Use of pass through code by non-ITS staff is a risk to the integrity of the web server. Restricting is a risk to perceived success of the implementation.

M M Risk to web environment will be assessed, policy will be recommended. Solution may satisfy both needs by allowing separate web environment for clients using pass through code.

Service ownership by ITS is inconsistent with other enterprise applications putting the division in a position to do functional support and training – typically not an IT function.

M M Web Service Definition team will need to clarify service ownership. Functional training and support are consistently identified by other universities as the most important roles and are often under the purview of a business unit rather than IT.


4 Technical Requirements

Infrastructure design is a deliverable of this project. The following technical requirements will be met:

• Production, test, and development environments

• Linux, Apache, MySQL

• Web site redundant and load balanced

• At least manual failover for WCMS application and database

• Servers hosted in the UCSC data center

• Integration with IDM for authentication

• Off- site disaster recovery strategy


5 Project Organization and Staffing

Executive Sponsors and the Web Presence and Services Program Team will have oversight and steering responsibilities of the WCMS Project until the Web Council and Web Steering Committees are established. At that time, the Web Presence and Services Program objectives will be subsumed into the Web Steering Committee.

Project sponsors will have the responsibilities of making business decisions regarding project issues and scoping statements.

Phase II of the WCMS Project will consist of one core project team and five sub teams. The core team will include sub-team leads at a minimum. Risks, issues and status are to be reported to the core project team on a regular basis. Unresolved issues will escalate to project sponsors.

Phase 2 will include the following sub teams:

• Core & deployment management (Core)

• Technical design and installation (Systems)

• Requirements, configuration, & development (Config)

• Site migrations and standard migration process (Migration)

• Documentation and communications (Comm)

Primary Project Team Members and Percentages Leslie Geary ITS, PMG All 80%

David Turner ITS, PMG Core 5%

Charles McIntyre ITS, AIG Core, Systems, Config 35%

David Rosen ITS, ASG Core, Systems, Config 35%

Galen Sullivan TBD Config, Migration 50%

Andrea Hesse ITS, CRM Core, Config, Migration 15%

Angela Thalls ITS, CRM Core, Config, Migration 30%

Rob Knight UR Core, Config, Migration 60%

Sue Roth Porter Migration 20%

Tom Gardner ITS, ASG Config, Migration 70%

Andre Daniels ITS, AIG Systems 40%

Jacques Delsemme ITS, AIG Systems 40%

Teresa Silva ITS, VC Ofc. Migration, Comm 15%

Marion Bashista ITS, PMG Core, Migration, Comm 25%


5.1 Staffing Chart

5.2 Roles and Responsibilities

ROLE NAME RESPONSIBILITIES

Executive Co-Sponsors

Donna Murphy, VC UR Mary Doyle, VC ITS

Ultimate authority and responsibility for a project or program Final approval for changes to scope Provides additional funds for scope changes Final approval of deliverables Makes user resources available

Project Sponsors Barry Shiller, UR CM Mark Cianca, ITS APM

Provide leadership in support of the project Makes business decisions for the program/project Disposes of issues and project scope change requests/orders

Web Program Manager

David Turner Provide day to day program leadership Participates day-to-day in one or more projects/sub-teams Works with PM to manage web program project


interdependencies

Project Manager Leslie Geary Responsible for project planning and facilitates approval processes Manages, reviews and prioritizes the project work plans with the objective to stay on time and on budget Manages project resources Coordinates and supports work packages and resolves issues to ensure progress according to schedule Reports status and issues to and receives feedback from the Executive Co-Sponsors, Project Sponsors, and Web Program Leadership Team. Manages and backs up Business Analyst Manages project communication

Core Project Team & Deployment Management – coordinate work package activities and deliverables and create a deployment plan for release of infrastructure, configurations, development projects, and migrations and assure release readiness. Team Lead Leslie Geary (In addition to PM responsibilities) Lead team, coordinate team

leads and deployment plan Engage vendor and other team members as necessary to create vendor scope of work Develop deployment / release communication plan As BA, integrate and represent business and technical perspectives from multiple teams, stakeholders, and vendor

Program Mgr, Interim Service Manager

David Turner Bring program perspective, service definition and service management perspective Work with project manager, app dev team lead, app admin team lead, and UR team lead to define operational roles and responsibilities.

Infrastructure and Tools Team, Technical Lead

Charles McIntyre

Represent System Design and Installation Team Define system release requirements, approve test plan Assure system environment release readiness Work with project mgr, program mgr, app dev team lead, and Rob Knight to identify project and operational roles and responsibilities

Web Applications Team, Technical Lead

David Rosen Represent Requirements, Configuration, and Development Team Define development release criteria Approve test plan Assure application development and configuration release readiness Work with project mgr, program mgr, web admin team lead, and Rob Knight to identify project and operational roles and responsibilities

Humanities and Porter Site Migration Lead

Angela Thalls Andrea Hesse

Represent Site Migration and Standard Migration Process Team (Humanities) Define site release readiness criteria Assure release readiness

University Relations Site Migration Lead

Rob Knight Represent both Site Migration and Requirements, Configuration & Development teams from UR perspective. Define University Relations site release readiness criteria Assure UR site release readiness

Process Analyst Marion Bashista Integrate of aspects of deployment plan, provide analysis re: process development, manage project timelines and documentation


Procurement- negotiate a contract with the vendor and complete the purchase of the application.

Buyers Nancy Nieblas & Donna Gorman, Procurement & Business Contracts

Communicate with vendor Manage contract review process Negotiate with vendor Complete purchase Participate in Procurement Planning Team Varied

ITS Procurement Planning Team

David Turner Leslie Geary

Review contract Recommend negotiation items Participate in Procurement Planning Team

System Design and Installation - design and installation of hardware, software, and process components supporting the application environment Team Lead Charles McIntyre Provide leadership in design and installation of technical

environment on which the application lives Lead installation and technical configuration of the application Present technical design to DRB

Application Dev Tech Lead

David Rosen Provide expertise and continuity from the application development and functional configuration perspective

Programmer/Admin Andre Daniels Planning: App Layer Installation: App Layer Tech config Other as determined by tech lead

Programmer/Admin Jacques Delsemme Planning: App Layer Installation: App Layer Tech config Other as determined by tech lead

Systems Admin TBD, ITS CT Installation: set up server environments.

Vendor Consultant TBD

Advisers & Resources

John Hammond Architectural and SDLC Review

Lisa Gardner Architectural and SDLC Review

Design Review Board

DBA Raji Sabbagh, ITS AIG Planning: Architecture design Planning: Database configuration Manage: Database install, configuration, failover mechanism, etc. Occasional

Systems Admin Gary Moro, ITS CT

Planning: Architecture design Manage: Sys admin resource and server environment set up. Occasional

Systems Admin Aaron Peterson, ITS CT Planning: Architecture design Occasional

Security Steve Zenone, ITS CT Planning: Architecture design

Network John Haskins, ITS CT Planning: Architecture design Manage: Network set up

Network Robert Cartelli Planning: Architecture design


VM Service Mgr Adele Guerzon, ITS CSS Planning: Architecture design VM Service Mgr

IDM Eric Goodman, ITS AIG Planning: IDM Integration

Business Requirements, Configuration, and Development - requirements elicitation, configuration and development of the application to meet user requirements Co-Lead Leslie Geary (In addition to PM responsibilities)

Provide team leadership especially in area of business requirements, configuration, development specifications, and testing Manage Business Systems Analyst Serve as part time business systems analyst

Co-Lead David Rosen Provide team leadership especially in area of functional configuration, development, and application development organizational structure. Work with co-lead to prepare and present materials for DRB as required. Provide status reports to PM for inclusion in monthly status reporting.

University Relations User Analyst Template Designer

Rob Knight Represent UR in defining requirements for UR business needs Help build UR specific solution for News/Events, Develop templates from RO designs

Business Systems Analyst

Galen Sullivan (work to be divided between Galen Sullivan, Tom Gardner, Leslie Geary, and perhaps Angela Thalls as time allows)

Master application functional configuration interfaces and parameters Anticipate business or technical ramifications of configuration alternatives Document business requirements * data definitions (data entry forms) * navigation/auto nav rules * taxonomies * required functionality for accessing shared content Analyze shared content requirements including course and faculty content data and UI reqs, identify conflicting requirements for escalation, propose technical and UI solutions in collaboration with developer, migration leads, and other systems utilizing authoritative course information/feeds (CLP, LMS, etc.) Recommend solutions and write specifications for * shared content delivery mechanism * configurations to meet business requirements * development * integration with external systems if applicable * data migration scripts * other Data analysis and cleansing for scripted migration of structured content and for data integration Communicate UCSC requirements to vendor BA Work with vendor and WCSM project teams to identify best practices for configuration and development based on business requirements Work with app dev team to implement functional configurations like “content types,” “configuration sets”, “asset factories”, “blocks,” workflow definitions, user roles, groups, file structure, common and unique metadata lists and taxonomies, etc. Develop test plan and lead unit testing of configuration and


developed solutions against requirements

Web Dev Team Tom Gardner Develop solutions based on specifications Work with business analyst and vendor to define best practices, development and configuration strategies based on requirements. Assist with Unit testing Help define operational roles and responsibilities based on configuration, development, and migration experience

Web Dev Team Paul Bauman TBD – may be assigned to development tasks.

Humanities Site Migration Team Lead


Represent Humanities business users

Infrastructure Team Charles McIntyre Represent system design and installation team Consult on configuration and development issues that impact technical infrastructure or vice versa.

Migrations and Standard Migration Process - migrate 3 or more sites into the WCMS, train users, and develop a high level standard migration process based on lessons learned during project migrations Humanities Migration Lead


Work with Humanities user analysts and staff to * set expectations * prepare site, cleanse content, * elicit requirements in collaboration with BSA (structured content, course information, etc.) In concert with PM, maintain communications with Humanities leadership as necessary for escalations, informal status reporting, clarification of priorities, establishment of expectations, etc. Provide status reports to PM for inclusion in monthly status Contribute to Standard Site Migration Process development

University Relations Migration Lead

Rob Knight Work with UR user analysts and staff to * set expectations * prepare site, cleanse content, * elicit requirements in collaboration with BSA (structured content, course information, etc.) * help define scope of migrations In concert with PM, maintain communications with UR leadership as necessary for escalations, informal status reporting, clarification of priorities, establishment of expectations, etc. Provide status reports to PM for inclusion in monthly status. Contribute to Standard Site Migration Process development

Porter College Migration Lead

Sue Roth Work with Porter user analysts and staff to * set expectations * prepare site, cleanse content, * elicit requirements in collaboration with BSA (structured content, course information, etc.) * help define scope of migrations In concert with PM, maintain communications with Porter leadership as necessary for escalations, informal status reporting, clarification of priorities, establishment of expectations, etc. Provide status reports to PM for inclusion in monthly status. Contribute to Standard Site Migration Process development

Humanities User Analyst(s)

Carrie Clark, Humanities Division Stephanie Bauman,

Work with migration lead to *identify site preparation requirements (data cleansing, UI


History Department Emily Gregg, Literature Department

reworking, content editing, design reqs), * execute preparations * determine migration scope * define requirements * participate in content migration * user testing of configuration, development, migration scripts, content migrated. Depends on scope

University Relations User Analyst(s)

Miscellaneous Work with migration lead to *identify site preparation requirements (data cleansing, UI reworking, content editing, design reqs), * execute preparations * determine migration scope * define requirements * participate in content migration * user testing of configuration, development, migration scripts, content migrated. Depends on scope

ITS Teresa Silva If Web Program pages are determined to be in scope, all migration lead and user analyst responsibilities apply

Business Systems Analyst

Galen Sullivan (work to be divided between Galen Sullivan, Tom Gardner and Leslie Geary)

Work with migration leads and user analysts to develop requirements User documentation Help develop training materials Help conduct user training Help develop migration testing plan

Web Dev Group Tom Gardner Represent web dev group, work with BSA on solution identification and specification, help with user training and migration testing

Process Analyst Marion Bashista Help develop standard migration process Develop standard migration process documentation

Documentation and Communication - collect and organize documentation and project communication

Team Lead Leslie Geary PM: coordinate communication, status reporting.

Process Analyst Marion Bashista Gather and organize documentation deliverables: user training, standard migration process, technical configuration, deployment plan, etc. Help complete project closure process and documentation

Web Communications Teresa Silva WCMS web site updates, project admin


6 Budget

The Phase II budget will be published internally under separate cover and will include:

• Application license

• Vendor implementation consulting

• Vendor on-going support

• Technical training/conference

• Technical infrastructure

• Disaster recovery solution may include a financial agreement with another entity.

Operational staffing costs are part of the overall program budget.

phase ii project plan v3.2 - web presence program · angela thalls humanities migration lead ......

Documents