ITS Project Management

Methodology
Information Technology Services
Project Management Group

11/17/2014
Version 2.1

Author: ITS Project Management Group

Document Control

Change Record

Date Author Version Change Reference

8/5/200 Marion 2.0 Major revisions and rearranged

9 Bashista content; added change
management, activities, and
outputs and deliverables;
revised Requirements Matrix

10/2/09 Marion 2.0 Updated per David Turner’s

Bashista review.

2/16/12 Marion 2.1 Updated process per revised

Bashista process flow approved by SMT

Reviewers

Sign Off Reviewer Position Sign Off

Date

Distribution

Copy Name
Number
Table of Contents

1 BACKGROUND

2 DEFINITIONS

2.1 Problem/Opportunities

2.2 Project

2.3 Project Management

2.4 Program

2.5 Program Management

2.6 Portfolio Management

3 PROJECT CLASSIFICATION

3.1 Why Do We Classify?

3.2 How Do We Classify?

3.3 Considering the Project Size Matrix

3.4 Considering the Project Risk Matrix

4 PROJECT MANAGEMENT METHODOLOGY

4.1 Define
4.1.1 Activities
4.1.2 Outputs and Deliverables

4.2 Plan
4.2.1 Activities
4.2.2 Outputs and Deliverables

4.3 Launch
4.3.1 Activities
4.3.2 Outputs and Deliverables

4.4 Manage
4.4.1 Activities
4.4.2 Outputs and Deliverables

4.5 Close
4.5.1 Activities
 4.5.2 Outputs and Deliverables

5 PROJECT CLASSIFICATION-METHODOLOGY REQUIREMENTS MATRIX

6 PROJECT INITIATION PROCESS FLOW

7 STANDARD ROLES AND RESPONSIBILITIES

7.1 Executive Sponsor (Class 4/5 Project)

7.2 Executive Committee (Class 4/5 Project)

7.3 Steering Committee

7.4 Program/Project Sponsor

7.5 Program/Project Manager

7.6 Team Lead

7.7 Team Member

7.8 Application Designer

7.9 Application Developer

7.10 Business Analyst

7.11 Customers

7.12 Stakeholders

8 GLOSSARY
1 Background

This ITS Project Management Methodology document provides Information

Technology Services (ITS) project teams with a set of standards to initiate and
manage individual projects. The Methodology provides tools to make the project
manager’s job a little easier. It contains definitions, guidelines, and templates for
the various project management activities needed to deliver successful projects.
The Methodology establishes common ground for all projects within UCSC ITS.
The ITS project management methodology development process was guided by
the following objectives:
▪ The design should seek to be reasonable, comprehensive, flexible, and
accessible.
▪ The content will enforce discipline but not disallow application of a
project manager’s critical judgment and insight.
The standards in this Methodology serve as assets to each ITS project manager
and team, and provide a common format for evaluating progress toward project
goals, objectives, and deliverables.
The Methodology encourages a top-down approach to project management. It ties
directly to the project life cycle phases and provides a more precise definition of
projects, a common lexicon used in project management, and a framework of
activities mapped to each project class size.
The ITS Project Management Group (PMG) built the Project Management
Methodology, a customized project management methodology, to enable ITS
project managers to focus on those processes that bring value. This methodology:
▪ Provides a common language for communicating and planning prior to
the start of the project work.
▪ Encourages appropriate communication and planning prior to the start of
project work
▪ Establishes a means for managing projects more efficiently
▪ Enables the tracking of progress against pre-determined metrics and
facilitates standardized reporting.
▪ Leads to effective project outcomes which achieve institutional objectives
▪ Builds on a set of best practices learned over time.
The long-term intent is to build a project management repository to document
best practices, lessons learned, and examples of various documents that may be
developed during a project.
The UCSC ITS Project Management Methodology is an adaptation of the project
management methodology described in Effective Project Management:
Traditional, Adaptive, Extreme, 3rd Edition, by Robert Wysocki and Rudd
McGary, and published by John Wiley & Sons in 2003.
2 Definitions

Project methodology makes assumptions about the use of specific terms and
project management issues. This section defines some of the key terms and
differentiates their use. Specific project roles are defined in Section 4—Standard
Roles and Responsibilities.

2.1 Problem/Opportunities
Problem/opportunities are those campus IT endeavors vetted and communicated
beyond the boundaries of the organization. They are those efforts that meet any
of the following conditions:
▪ Have an impact beyond the division sponsoring the effort (e.g. changes or
creates a new process or a procedure or function)
▪ Create benefits beyond the sponsoring division
▪ Initiate a partnership with an external stakeholder (e.g. Regulatory
requirements)
▪ Influence or are influenced by strategic planning
▪ Require resources external to the unit/organization to successfully
complete the problem/opportunities
Through the process of program and project structuring each campus
problem/opportunities may develop into programs or a set of projects for
implementation.

2.2 Project
A project is group of related work activities organized under the direction of a
project manager which, when carried out, will achieve specified objectives within a
stated timeframe.
A project has a defined scope, deliverables or outcomes, work steps, duration, and
budget as defined in a Project Charter.
A project
▪ Is temporary with a distinct beginning and end
▪ Is a minimum of 80 hours
▪ Is defined by specific deliverables
▪ Is conducted by a temporary team that exists for its execution
▪ Has a single project manager who is responsible for its success
▪ Is defined by identifying the starting point, the goal/objectives, and the
route between them
2.3 Project Management
Project management defines managing single projects that meet the following
general guidelines:
▪ The project has a logical scope.
▪ Duration is typically from 3 months to 5 years.
▪ Team size is typically less than eight members including the project
manager.
▪ There is a single project sponsor.
▪ There is a single project manager.

2.4 Program
A Program is a group of related projects that address a common business goal or
problem/opportunities.
Individual projects comprising a program are interdependent and must be
successfully completed for the business program to meet its objectives.
Programs provide a means of organizing and managing large, complex, or
longer-term project efforts. The overall effort is subdivided into a set of small
interdependent projects, each of which implements some portion of the overall
solution.

2.5 Program Management

Program management is the means by which multiple projects are managed to
achieve a common strategic business goal or objective. Program management may
be applied to any opportunity too large to address with a single project.

2.6 Portfolio Management

Portfolio Management is the process by which a set of campus
problem/opportunities are identified, evaluated, ranked, matched to available
funding, and approved for implementation. It requires consultation and close
collaboration of the IT function, clients and key executive stakeholders, and
sponsors. Portfolio management is a key governance process for the activities of
the IT function.
The goal of portfolio management is maximization of the total value realized by
the implementation of a set of proposed problem/opportunities given finite
funding and resources.
Portfolio management must be tightly integrated with program and project
management so that problem/opportunities can be properly scoped, estimated,
and structured into programs and projects.
3 Project Classification

The Methodology is not a one-size-fits-all methodology. Rather it is an approach

that specifies the processes used to manage a project based on its characteristics.
Those characteristics are defined so that classes of projects are formed and so that
each class has its own specification as to which parts of the Methodology are
appropriate.

3.1 Why Do We Classify?

The amount of documentation and required project management activities should
scale to size of each project. This approach is strongly advocated as it adapts the
methodology to the project.
The value of the characteristics are used to determine which parts of the project
management methodology must be used and which parts are left to the discretion
of the project manager to use as he or she sees fit.
In the final analysis, defer to the judgment of the project manager. Apart from
those required by the organization, the project manager should adopt whatever
parts of the methodology he or she feels will improve their ability to help
successfully manage the project.

3.2 How Do We Classify?

All projects can be classified into a project class based on the amount of work
effort and risk. A small project would fall into Class 1 while a very large project
would fall into Class 5. The amount of documentation and required project
management activities scales to size of each project.
Classification is a two-step process.
▪ First, using the Project Classification – Sizing Matrix, the initial class of
the project is determined.
▪ The second step uses the Project Risk Matrix as a ‘modifier’ of the
project’s initial class to determine the actual class.

3.3 Considering the Project Size Matrix

Project class is initially determined based on work effort represented by the
estimated duration (not number of person-hours) required to complete the work.
 Table 3.1 - ITS Project Classification Sizing Matrix

3.4 Considering the Project Risk Matrix

Although work effort is a good indicator for the amount of project management
that should be expended, certain factors can also bring about the need for the
application of more robust project management practices.
The Risk Matrix identifies six risk factors to be evaluated once the initial
classification level is determined. In the event that the total risk score is greater
than 10, the classification level should be increased.

Table 3.2 - ITS Project Classification Risk Matrix

4 Project Management Methodology

A project management methodology is a:

▪ Conceptual framework for program and project management
▪ Set of guidelines, standards and processes
It is an evolving vehicle for sharing and communicating lessons learned and best
practices for program and project management.
The purpose of a project management methodology is to:
▪ Provide project managers and teams advice and guidelines to deliver
better and consistent project results
▪ Provide a common language and framework describing programs,
projects and the practice of project management
▪ Provide project managers a means of sharing and leveraging experience,
lessons learned, and best practices.
The methodology described here is intended to be a starting point for the project
manager to think about structure and manage their projects. It is a work in
progress. It is the PMG teams’ intention that this methodology will be augmented
and refined over time by the collective experience at UC Santa Cruz.
The methodology outlined here is a synthesis of current practices on the campus
and specific methodologies employed by consulting firms and other organizations
worldwide. To simplify the design and execution of campus projects, this
methodology is comprised of five project management phases.

Figure Number 1
Project Management Phases

Each phase addresses a specific aspect of managing a project from define through
close. Although these phases are described sequentially in practice, some may
overlap or be applied concurrently.
The results of each phase are described by a set of project management
deliverables or artifacts. These artifacts provide visibility to application of the
methodology and clear communication to project stakeholders. Each of these
phases and deliverables are described in more detail in the sections that follow.
4.1 Define
The first phase of the project management life cycle is the define phase. This
phase is the one most often given the least attention. The define phase scopes the
project.
When a project is in the early phases an initial high level Project Proposal should
be created. This allows the project sponsor and project manager to quickly
understand the dimensions of the project and identify alternate approaches. At
this phase, the process is exploratory in nature and it is not always certain that the
project will proceed. It is not advisable to spend too much effort on scoping the
project. A rough order of magnitude estimate of project resources (costs, FTE’s)
and schedule will suffice for moving the project through the first phase of the
project management process.

4.1.1 Activities
Once the initial definition of the project is complete, it is documented in the form
of the Project Proposal. The Project Proposal is a brief document (usually one
page) that describes, in the language of the business, the following.
▪ What is the problem or opportunity to be addressed by the project?
▪ What are the projects’ goal and objectives?
▪ How will success be measured?
▪ What is the high-level budget and timeline for the project?
▪ What assumptions, risks, and obstacles may affect the project that you
wish to call to the attention of senior management?
At this point, a “Go/No Go” decision is made by the project sponsor and an ITS
Manager, for class 1 and 2 projects, or ITS Senior Management Team (SMT), for
class 3 and larger projects.
○ If the project is approved at this phase, it moves to the next phase, Plan
where the project charter is developed.
○ If the project is not approved for further consideration then the reasons
for not approving it and the initial project charter serve as a record of the
governance process.

4.1.2 Outputs and Deliverables

Outputs and deliverables from the Define phase of the project management life
cycle are:
▪ Sponsor approval
▪ ITS Manager approval (small projects)
▪ ITS Director approval (large projects)
▪ Completed Project Proposal
4.2 Plan
This second phase of the project management life cycle focuses on scoping and
planning the project. Details about the project are determined, including an
estimated timeline and budget.
These details are captured in the complete Project Charter. The Project Charter is
used to provide greater clarity on the scope of the project and how the objectives
will be achieved. The Project Charter also documents the agreement between the
project manager and the project sponsor for a successful project completion.

4.2.1 Activities
Using documents produced in the define phase, the project manager, core team
and key client representatives develop a detailed project plan. The plan defines the
time, cost, and resource requirements needed to deliver the functionality identified
in the define phase.
Key questions that need to be answered in this phase are:
▪ Why is the program or project needed? (Objectives)
▪ What outputs or results will the project need to produce? (Deliverables
and Outcomes)
▪ How long will the project take and what people and roles will be needed
to execute it? (Workplan)
▪ What are the project costs and benefits?
▪ How will risks be managed?
▪ What are the detailed resources (costs, FTE) required?
The Project Charter is refined to identify specific resources and roles, approach,
deliverables and a work plan. In addition, a project risk assessment should be
developed.
A risk assessment identifies potential risks and defines the appropriate risk
mitigation strategies. The risk assessment may result in changes in the project
scope, timing, role assignments, and cost. The Project Charter should be updated
reflecting this new information.
Once the more detailed Project Charter has been developed, the project will be
subject to a second “Go/No Go” decision by the project sponsors and the IT
Portfolio Management governance process. If the project is approved on this
second iteration, resources will be assigned and the project will be launched.
During the Plan phase, a temporary project manager may be assigned to work
with the sponsor(s) to develop the Project Charter, project plan and risk
assessment. Once the project is approved for mobilization, the final project
manager assignment will be made.
For governance reasons and for practical purposes the project charter is
developed in an iterative manner. Two “Go/No Go” decision points are included
in the Plan phase to move the project from concept to launch.
4.2.2 Outputs and Deliverables
Outputs and deliverables from the Plan phase of the project management life
cycle are:
▪ Sponsor approval
▪ ITS Manager approval (small projects)
▪ ITS SMT approval (large projects)
▪ Completed Project Charter
▪ Completed Project Budget
▪ Assigned and approved project staff resources
▪ Analysis of APM User Interface Standards

4.3 Launch
At this phase, a specific project governance structure is established (Executive
Sponsor, Project Sponsor, Steering Committee etc.). The project organization is
finalized. Project team members are cast in their roles and briefed on the project
by the assigned project manager. The project team members refine the project
work plan as necessary and are assigned responsibility for their specific tasks and
deliverables.
The figure below shows a typical project organization structure. The roles in the
diagram are described in the Standard Roles and Responsibilities section.

Figure Number 2
Typical Project Organization

The project manager leads and coaches the team to achieve the goals of the
project. The project manager works collaboratively with the Project sponsor to
guide the efforts, update the plan, resolve project issues, and to obtain key
business decisions when necessary.
During this phase, the project issue log is a key tool to capture issues and their
resolution. An issue is a formally defined matter that may impede progress of a
project or a program for which no agreement has been reached. The project issue
log tracks issues and key decisions.

4.3.1 Activities
▪ Project kick-off meeting
▪ Team assignments
▪ Assess and review project plan

4.3.2 Outputs and Deliverables

▪ Resource requirements
▪ Issues and risks logs

4.4 Manage
The Manage Phase of a project includes all of the tasks that the project manager
and team must do in order to keep the work of the project moving along as
planned. This phase runs throughout the life of the project to keep stakeholders
informed and to engage their active involvement and sponsorship for the project
or program.
Reporting project status is a critical success factor at this phase for managing
expectations of project sponsors, the project steering committee, and other key
stakeholders. Regular and effective reporting is critical synchronization of multiple
projects within a program.
The two aspects to communications in this phase are internal and external project
communication and formal or informal communication.
○ Formal reporting may be sponsor or committee briefings, presentations,
or written reports.
○ Informal reporting can be minutes, “management by walking around”, or
sponsor and team discussions.
Formal external reporting to Steering Committees and Executives should be built
into the project calendar. This allows time for preparation and alignment with the
end of major project phases or the key milestones. Project manager/project
sponsor meetings should focus on
▪ resolving issues
▪ reviewing deliverables and work products
▪ project milestone progress
For formal internal reporting, standing meetings should be established for the
project team and the project sponsor and project manager. The frequency of these
meetings should be appropriate to the duration of the project. At minimum, these
should be weekly meetings. Project team meetings should focus on
▪ reviewing task progress from the previous period
▪ reviewing tasks for the next period
▪ reviewing the issue log
Meetings of the project team, project manager/sponsor should be scheduled to
give project team a sense of the larger context of the project and to enable
interaction between the project sponsor and the whole team. This interaction is
important from a collaboration perspective and provides an opportunity for the
project sponsor to demonstrate their interest and active sponsorship in the
project.
A regular and appropriate reporting mechanism for the project can be a fine
balancing act. Over- or under-communicating leads to “tuning out” or feeling “in
the dark”. The need for formal, regular reporting for the project manager and
project sponsor can cost the team too much time in meetings and writing reports.
This can detract from other project activities or can lead to inadequate status
reporting. A defined minimum level of reporting must be implemented. Team
members need to meet these minimal reporting requirements.

4.4.1 Activities
The project work is underway and the focus of the project manager changes from
project planning to project execution. The project manager’s job will be to manage
the work of the project.

4.4.1.1 Executing the Project Plan and Status Reporting

Once the project is underway, the project manager makes sure it proceeds
according to plan. To do this, he or she needs to establish a reporting system to
inform sponsors and the team.
Regular status reports provide visibility to the true state of a project. Status reports
keep sponsors informed about the project’s progress, issues, and accomplishments
in the areas of schedule, resource, and budget management.

4.4.1.2 Risk and Issue Management

Risk and issue management identifies factors that can affect the outcome of the
project and that you want to bring to the attention of senior management or
sponsors. These factors can affect deliverables, schedule, and other conditions
that are relevant to the project. You want to record anything that can go wrong
and include whatever contingencies can help reduce the impact on project success.
Do not assume that everyone knows what the risks and issues are. Document
them and discuss them.

4.4.1.3 Communication Management

Successful projects involve good, clear communication. A communication plan
helps the project manager and team think about the different types of
communications that can be used during the project. Examples of these
communication types include
▪ project status reports
▪ team meetings
▪ traditional communication to stakeholders via email
▪ informal communications using email or phones
Strong communications helps the project manager, client, and the project team
share project progress information.

4.4.1.4 Project Change Control

It is difficult for anyone regardless of skill to define completely the scope of a
project. Customer requirements, technology changes, and many other factors
could bring a project to a halt. Good project management methodology has a
project change control process in place. In effect, the project change control
process has you plan the project again. Change control refers to scope changes
requested during the life of project. Once a project has been approved, any change
affecting the project scope requires a change project control request documenting
the change be completed.
The project change request form is part of every good project change control
process. The first principle to learn is that every change is a significant change.
Every change requested by the client must be documented in a project change
request form. That document might be as simple as a memo but might also follow
a format provided by the project team. Only when the request is clearly
understood can the project manager and project team evaluate the impact of the
change and determine whether the change can be accommodated.

4.4.1.4.1 Project Change Outcomes

There are six possible outcomes from a project change request:

▪ It can be accomplished within the project’s original resources and
timeline.
▪ It can be accomplished but will require an extension of the project’s
deliverable schedule.
▪ It can be accomplished within the project’s deliverable schedule, but will
require additional resources.
▪ It can be accomplished, but additional resources and an extension of the
deliverable schedule will be required.
▪ It can be accomplished with requires a new release strategy and
reprioritizing of the deliverables.
▪ It cannot be accommodated without a significant change to the scope of
the project.

4.4.1.4.2 Initiating a Change Control Request

Documentation is an integral part of the change control process. All project scope
changes should follow the same change control procedure. The process is initiated
with the submission of a change request from the manager or client and the form
is forwarded to the sponsor for review. The sponsor may either accept the change
or return it to the manager/customer for rework and resubmission. All changes to
scope are documented and authorized by the relevant stakeholders. Once the
change request has been accepted, it is forwarded to the project manager for an
impact review. Any change to project scope must be communicated to the project
manager.
The project manager ensures that the change request form has been completed
and reviews the form to see if there is an impact to the schedule. If any task,
schedule, or resource information has been changed, the project manager needs to
communicate the changes to the project team. The project manager also needs to
communicate any change in the committed timelines to the relevant stakeholders
(manager, customer, or any other project manager whose project is dependent on
the completion of this project). The request is analyzed by the project manager
and project team. Based on the estimated effort, time and cost required
implementing the change; it is approved, denied, or returned to the requestor for
additional information. Changes resulting in additional costs require a new budget
analysis be done. Any change needs to be communicated to the governance
structure. The project manager and established governance may approve or deny a
change request. They may decide if the customer needs to pay for implementing
the change.

4.4.2 Outputs and Deliverables

Outputs and deliverables from the Manage phase of the project management life
cycle are:
▪ Revised project schedule/work breakdown structure (WBS), as needed
▪ Status reports
▪ Issues/Risk Logs
▪ Change Control Review
▪ Updates to schedule and budget, as needed
▪ Communication to sponsor and stakeholders

4.5 Close
Program and project management is a temporary endeavor. All programs and
projects end. The ending needs to be a deliberate and explicit process to ensure
the project closes with the appropriate hand-offs and knowledge transfer. The
Close phase is conducted once the project team has met all deliverable
commitments. In some cases, the project will be terminated due to changes in
business circumstances, changes in sponsorship or a failure to meet project
objectives.
The Close phase is used to:
▪ Formally end the project.
▪ Evaluate the project assessing performance against objectives, budget, and
schedule.
▪ Examine the project for improvements in approach for future projects.
▪ Package information for reference by future projects.
The Close phase provides a basis to continuously improve and enhance project
management methodology using examples, templates, lessons learned, and process
and technique improvements.

4.5.1 Activities
There are several activities in the Close phase of a project.
▪ Acceptance of deliverables – This activity is usually accomplished via a
checklist. This can be a very formal or informal process.
 ▪ Transition to production – For most projects there is some form of
transition to production and/or operations.
▪ Administrative closure – The project is not done until the paperwork is
filed.
▪ Lessons learned – This is an evaluation review of the project’s goals and
deliverables as measured against the project proposal or charter as a
baseline.
▪ Release resources
▪ Celebrate

4.5.2 Outputs and Deliverables

Outputs and deliverables from the Close phase of the project management life
cycle are:
▪ Final Sponsor and customer review and approval
▪ Operational Readiness Review
▪ Lessons learned review with project team with final documents submitted
to SMT
▪ Administrative Closure
5 Project Classification-Methodology Requirements
Matrix

The number of activities required for a given project depends upon the class into
which the project is categorized. A class 1 project will involve only a few of these
activities. A class 5 project will involve all the activities in the framework. The
activities required for each class are the bare minimum. It depends upon the
discretion of the project manager to perform other activities (even if they are not
recommended) if he or she feels that the activity is needed for the project.
The Methodology Requirements Matrix shows how the activities are currently
mapped to the project classes along with the appropriate artifacts for each activity.
Artifact templates are not contained within this document but can be found at the
ITS Project Management Group website at
<http://its.ucsc.edu/project-management/templates.html >.
The required activities for each project class are the minimum needed for effective
management and status reporting of a project. The project manager and project
team may add additional activities. The additional activities should not be added
merely as an exercise but should contribute added value to the project.
Table 4.1 - ITS Project Classification Methodology Requirements
Matrix
6 Project Initiation Process Flow

Figure Number 3
UCSC ITS Project Initial Process Flow – Determine Type of Work
 Figure Number 4
UCSC ITS Project Initial Process Flow - Define
 Figure Number 5
UCSC ITS Project Initial Process Flow – Plan through Close Class 1
 Figure Number 6
UCSC ITS Project Initial Process Flow – Plan through Close Class 2
 Figure Number 7
UCSC ITS Project Initial Process Flow – Plan through Launch Class 3
 Figure Number 8
UCSC ITS Project Initial Process Flow– Plan through Launch Class 4
 Figure Number 9
UCSC ITS Project Initial Process Flow– Plan through Launch Class 5
 Figure Number 10
UCSC ITS Project Initial Process Flow– Plan through Close Class 3+
7 Standard Roles and Responsibilities

This section describes typical roles and responsibilities for projects and programs.
Roles may be assigned to one or more individuals. Conversely, individuals may
play one or more roles.

7.1 Executive Sponsor (Class 4/5 Project)

▪ Has ultimate authority and responsibility for a project or program
▪ Approves changes to scope
▪ Provides additional funds for scope changes
▪ Approves deliverables

7.2 Executive Committee (Class 4/5 Project)

▪ Allocates resources to support project implementation
▪ Advises on issues escalated by Steering Committee
▪ Exemplifies rapid analysis and decision-making characteristics imperative
of all project team members
▪ Prioritizes project to demonstrate its importance and timeliness across
other UCSC objectives
▪ Recommends a communication plan within the UCSC community
▪ Provides information and expert advice about campus plans for other
projects or system developments that impact project timelines,
deliverables, or resources
▪ Recommends resolution of scope related matters
▪ Advises on strategic partnerships

7.3 Steering Committee

▪ Provides campus wide leadership in support of the project
▪ Resolves issues escalated by the project manager or project team leads
▪ Resolves or forwards policy issues to appropriate decision-making bodies

7.4 Program/Project Sponsor

▪ Makes the business decisions for the program/project
▪ Participates day-to-day in one or more programs/projects
▪ Makes user resources available
▪ Approves work products
▪ Disposes of issues and project scope change requests
7.5 Program/Project Manager
▪ Reports to and receives direction from Executive Sponsor
▪ Participates in and approves project plan and deliverables
▪ Manages, reviews, and prioritizes the project work plans with objective to
stay on time and on budget
▪ Provides status and progress reviews to Executive Sponsor and Steering
Committee
▪ May manage and supervise the following resources:
○ Senior technical staff
○ Technical project managers
○ Team leads
○ Team members
▪ Manages project resources
▪ Reports status to and receive feedback from Steering Committee
▪ Collaborates with project managers to resolve issues within individual
projects or within portfolios
▪ Brings issues to the Steering Committee as needed
▪ Recommends resource and policy changes to the Steering Committee
▪ Identifies required project team members and constructs project teams
▪ Meets with project managers to regularly review issues and monitor
progress
▪ Motivates and coaches project managers and team members
▪ Monitors contract compliance
▪ Approves job orders and change orders
▪ Conducts risk management analysis
▪ Meets facility and resource requirements
▪ Reviews and approves deliverables

7.6 Team Lead

▪ Assigned full or part time to participate in project team activities
▪ Responsible for contributing to overall project objectives and specific
team deliverables
▪ Manages specific project plan activities and contributes to project plan
development in collaboration with project manager
▪ Coordinates documentation, testing, and training efforts related to project
plan

7.7 Team Member

▪ Assigned full or part time to participate in project team activities
▪ Responsible for contributing to overall project objectives and specific
team deliverables
▪ Escalates policy issues to team lead for referral to appropriate policy
making bodies
7.8 Application Designer
▪ Designs systems from a user perspective
▪ Designs human factors (windowing, ease-of-use)
▪ Designs externals (screens, reports, forms)
▪ Designs usability of the application
▪ Acts as technical design specialist
▪ Designs application software components, including programs, modules,
and run units
▪ Work with clients and APM SMEs to analyze and incorporate the User
Interface Standards

7.9 Application Developer

▪ Prototypes, develops, and unit tests application software components or
fragments
▪ Typically knowledgeable in one or more development environments
▪ Develops against accepted institutional development standards using
systemwide business policies (Business and Finance Bulletins IS-3 and
IS-10)
▪ Participates with Business Analysts in application documentation

7.10 Business Analyst

▪ Assesses current systems
▪ Develops and maintains models of business requirements
▪ Designs business transactions
▪ Designs and organizes procedures
▪ Documents and analyzes business processes using
value-added/non-value-added, process modeling tools, cost-time charts,
and root cause analysis or other tools as appropriate
▪ Documents “ability to” functional requirements for use by application
designers and developers
▪ Is an active participant in unit testing, system testing, and regression
testing

7.11 Customers
▪ Initial identifier of need or service
▪ May be designated as subject matter experts (SME) for functional
requirements definitions and testing

7.12 Stakeholders
▪ Community member affected by or participating in the project
▪ May be internal or external to the organization
8 Glossary

Term Definition

Activities The next level of detail below deliverables. A deliverable is complete when all its activities are done.
“Procure and set up 4 VM machines with Windows OS…”

Change Control The review, approval/disapproval, implementation, tracking, closure, and status reporting of proposed
changes to project deliverables.

Closure The last phase of a project life cycle ­­ resources are released, contracts are closed, deliverables are
accepted by the customer, lessons learned are documented, project team celebrates.

Contingency Plan An alternative for action if things do not go as planned or if an expected result fails to materialize.

Critical Path The sequence of tasks in a project with zero slack time. Defines the minimum project duration.

Decomposition The act of breaking work down into activities, tasks, sub­tasks, and work packages.

Deliverable A report or product that must be completed to ensure satisfaction of project requirements.

Dependencies A relation between project activities, such that one requires input from the other. The relationship can
exist within a single project or across a suite of projects.

Goals Project performance indicators set at the beginning of the project that reflect directly on the key
objectives of the project and provide the basis for ratings during project status appraisals.

Governance The processes, decision rights, and accountability at various levels of the institution to manage ITS
functions.

Investment Those endeavors with impact and benefit beyond the sponsoring division. They may have external
opportunity stakeholders, be influenced by strategic planning or require external resources for success.

Issue A formally defined matter that may impede progress of a program or project.

Labor (or Effort) The amount of “work” associated with completing a task, usually expresses in person­hours. Think of it
as the amount of time it would take for one person to do a task in one continuous period without
interruption.

Launch The process of preparing for, assembling resources and getting work started. It is the process of
committing an organization to begin a project.
Milestone An action or event marking completion of a major deliverable or other significant change in a project.

Phase gate Approval points during a project lifecycle phase where decision are made to move the project to the
next phase or to closure.

PMBOK Project Management Book of Knowledge – The high­level guide to project management methodology
published by the Project Management Institute (PMI).

Portfolio Process by which a set of campus problem/opportunities are identified, evaluated, ranked, matched to
Management available resources and approved for implementation.

Program Group of related projects addressing a common business goal or problem/opportunities.

Program Means by which multiple projects are managed to achieve a common strategic business goal or
Management objective.

Project A group of related work activities organized under the direction of a project manager which, when
carried out, will achieve specified objectives within a stated timeframe.

Project Charter A document consisting of a problem/opportunity statement, background, purpose, and benefits, goals
Document and objectives, scope, assumptions and constraints.

Project Duration Total time it will take to complete the project in calendar days/months/years.

Project Life Cycle The complete history of a project through define, plan, launch, manage, and close phases.

Project Application of modern management techniques to execute a project from start to finish, achieve
management predetermined objectives of scope, quality, time and cost, to the equal satisfaction of those involved.

Project A set of general project activities and deliverables mapped into the five phases of the project lifecycle.
Management
Methodology

Project Plan An optimized, detailed, living schedule of all tasks and resources in a project.

Project Proposal A document consisting of a problem/opportunity statement, including background, purpose, and
benefits, a goal, objectives, scope, assumptions and constraints. A Project Proposal clearly documents
project definition in order to bring a project team into necessary agreement.

Risk The cumulative effect of the chances of uncertain occurrences adversely affecting project objectives.

Risk Identifies potential risks and defines appropriate mitigation strategies.

Management

Scope Bounded set of measurable deliverables of a project.

Scope Creep On­going requirements increase without corresponding adjustment of approved cost and schedule
allowances via change management process.

Sponsor Individual(s) with ultimate authority, approval, and responsibility for a project.
 Stakeholders Campus community member affected by or participating in a project. One with a stake or interest in the
outcome of the project. Also one affected by the project.

Work Breakdown Tool that defines the hierarchal breakdown of all work in a project.
Schedule (WBS)

Work Package Detailed short­span tasks that represent a further breakdown of the project work breakdown schedule
(WBS)

Project Management Group

Information Technology Services
University of California, Santa Cruz
1156 High Street
Santa Cruz, CA 95064