Project Management Process

Statement of Best Practice

The purpose of project management is to deliver project outcomes that align with university needs on-spec, on-time, and on-budget 

  • To provide defined repeatable, auditable, scalable processes (example: clear transition of work, etc) in how projects and requests for change are managed
  • Follow standards to manage the work, track and report progress, and control the outcomes
  • Transparency through visibility into project activity, status, risk, issues
  • Effective communication with stakeholders through partnerships &  collaboration
  • Set and manage expectations of all participants to ensure that the process results in successful outcomes
  • Make informed decision by utilizing appropriate resources (team, sponsor, stakeholders, users, etc.) to make decisions throughout the project/request for change

Contact

  • Assistant Director, IT Process and Planning: Bob Black
  • Process Owner: Kent Covert
  • Process Sponsor: Brian Henebry

Roles and Responsibilities

The project management process defines the following process-specific roles and responsibilities:

  • Project Sponsor: person with demonstrable interest in the outcome of the project who is responsible for securing spending authority and resources for the project; acts as a vocal and visible champion, legitimizes the project’s goals and objectives, keeps abreast of major project activities, and is a decision-maker for the project
  • Stakeholder: an individual, group or organization that may affect, be affected by, or perceive itself to be affected by a decision, activity or outcome of the project
  • Key Stakeholder: a subset of Stakeholder who, if their support were to be withdrawn, would cause the project to fail
  • Project Manager: person who has the overall responsibility for the successful initiation, planning, design, execution, monitoring, controlling, and closure of a project
  • Resource Manager: person or persons providing resources for the project

 

Design Package

The design package identifies how each of the roles is involved in one of four approaches. Use the following guidelines to determine which approach to use:

Factor 1 Factor 2 Recommended Approach
Low complexity, low risk, low breadth of skills, less than one month in duration, low impact, low vendor/contractor involvement, low client engagement Team preference Kanban: Agile approach for dealing with less-complex projects
Low complexity, low risk, low breadth of skills, less than one month in duration, low impact, low vendor/contractor involvement, low client engagement Team preference Linear: Traditional waterfall approach for dealing with less-complex projects (fewer artifacts at each gate)
High complexity, high risk, greater than one month in duration, medium-high impact High vendor involvement, low client engagement, low collaboration, requirements well-known up front, low urgency Traditional: Waterfall approach for dealing with complex projects (more artifacts at each gate)
High complexity, high risk, greater than one month in duration, medium-high impact Low vendor involvement, high client engagement, requirements unclear, high urgency Scrum: Agile approach for dealing with complex projects

The specific individuals performing the activities of these roles can vary project by project and a single person may assume multiple roles. These are intended as guidelines to create a uniform experience from project to project.

Process Policies

  • All requests that are not incidents or service requests must follow the project and/or change management process.
  • Improvements and challenges to use the production process will be registered with the process owner.
  • If the client is unavailable to fulfill their responsibilities as defined and agreed upon at the beginning, the team will advance to the next project.
  • All projects require an identified client requester, documented justification, desired outcomes, and architecture (build/buy/modify existing) to begin.
  • All projects require a clearly defined definition of done, approach, and budget (including time commitment) with agreement from the requester/client.

Definitions 

  • Project: 
  • Program: 

Related Documents, Forms, and Tools 

Was this helpful?
0 reviews