IT Project Management Standard



The University of Mary Washington is committed to continuously improving the delivery of information technology (IT) solutions within budget, on schedule, within scope and in such a way as to best contribute to accomplishing the university’s strategic mission. To this end, the University has established a standardized IT project management methodology based on proven “best practice” guiding principles as promoted by the Project Management Institute appropriately tailored to the specific circumstances of the university.

This standard and associated guidelines were developed in full accordance with and in support of the UMW Information Technology Project Management Policy and will be maintained by the UMW Project Management Office (PMO). The PMO will monitor the future development of project and portfolio management best practices and incorporate into UMW’s methodology those that are proven to improve project performance in a higher education setting.


The Commonwealth of Virginia Restructured Higher Education Financial and Administrative Operations Act of 2005 and Chapters 824 and 829, Virginia 2008 Acts of Assembly grant public institutions of higher education certain operational authority in the areas of information technology and procurement, on condition that certain commitments to the Commonwealth are met. The University of Mary Washington’s Memorandum of Understanding with the Commonwealth provides delegated responsibility for management of the institution’s procurement and information technology project management. This delegation includes the authority to conduct these activities in accordance with industry best practices appropriately tailored for the specific circumstances of the university, in lieu of following Commonwealth determined specifications. Responsibility for IT projects costing under $2 million is delegated to the university to approve and manage such projects in accordance with industry, Commonwealth, and/or Project Management Institute (PMI) best practices.

IT projects costing $2 million and over remains under the purview of the Commonwealth’s Chief Information Officer (CIO), and the Project Management Division (PMD) of the Virginia Information Technologies Agency (VITA).

The President of the university has final project management oversight authority and may review, suspend or terminate any project.


This standard establishes the required processes and documentation for all University information technology projects.


This standard is applicable to all IT projects implemented by UMW faculty, staff, students, contractors, business partners, and IT service providers.


Project Definition

The definition of a project covered by this standard is a temporary information technology endeavor with an established beginning and end time that has a set of defined tasks and assigned resources, undertaken to develop a unique product, service or result.

An information technology project is a temporary effort undertaken by or on behalf of the university that:

  • Establishes a new technology-based system or service
  • Facilitates a significant business process transformation using technology; or
  • Includes a major change in technology architecture or a system migration beyond that considered as general maintenance, enhancement, or refresh activity

In our organization a project typically performs one or more of these functions:

  • Develop a new system or service
  • Improvements to a system or service
  • Improve business processes or introduce new ones
  • Build or enhance infrastructure
  • Apply new technology
  • Upgrade enterprise applications

Some examples of work that are NOT projects:

  • ETF/Operation efforts
  • System administration
  • System operations
  • Break/fix activities
  • Customer support

Activities undertaken in support of an existing product or service will not be defined as projects for the purposes of this standard, so long as the bulk of the effort involves continuation, with improvement, to the current product or service. Significant cost for a procurement or operational activity does not make the procurement or activity a project. For example, routine software upgrades or network component replacements are not necessarily projects. Utilization of project management principles and techniques in the management of maintenance and operational activities are encouraged, whether they are defined to be projects or not.

“Projects and operations differ primarily in that operations are ongoing and produce repetitive products, services, or results. Projects (along with team members and often the opportunity) are temporary and end. Conversely, operations work is ongoing and sustains the organization over time. Operations work does not terminate when its current objectives are met but instead follow new directions to support the organization’s strategic plans.” (PMBOK, Fourth Edition)


If an individual/department is considering an information technology project, they are encouraged to work with Information Technology to assure appropriate analysis, classification, approval and documentation steps are undertaken. In addition to promoting good technology management decisions within the university, these steps also assist the university in meeting requirements set forth in Commonwealth of Virginia policies and standards.


Prior to soliciting acquisition or development of an information technology project, the following steps must be completed:

  1. Define the idea or need to be addressed by this project. Be able to communicate the project purpose and scope clearly to others.
  2. Submit the IT Project Research Form (PRF) on line at   Any inquiries should be directed to the PMO for Information Technology at ext 5975.
  3. The PRF notifies the Technology Portfolio Management Committee and initiates the Project Research Phase. During the Project Research phase the requestor begins the process of investigating possible solutions, scheduling demos, gathering information, and answering questions.
  4. At the conclusion of the Research Phase, a potential solution/system is identified and an IT Project Approval form is submitted. During the Approval phase, the form goes to the Technology Portfolio Management Committee for review and recommendation to the Cabinet.
  5. Following Approval, the project moves to Project Management. At this point, IT PMO will review the requested solution/system with the PMO team. IT PMO will work with the project initiator to collect any additional information and complete any further analysis that may be necessary.
  6. In general, the level of oversight during the selection and management of technology projects varies with the cost and complexity of the project. For this purpose, projects are first classified as either major or non-major:

A major information technology project is one:

  1. For which the costs, from project initiation to project closeout (generally operational production go-live), are greater than $1M. These costs are to include all hardware and software costs. Salaries for technical and functional personnel are to be considered part of the project costs and the individual’s involvement will be tracked as a project expense.
  2. That is of such significance to the university that failure to achieve its expected outcomes could prevent UMW from accomplishing its mission or meeting its legal obligations until a workable alternative could be established; OR
  3. Set forth by the Virginia Information Technologies Agency (VITA) as having “statewide application”.

Non-major information technology projects are those technology projects that have an estimate total project cost of less than or equal to $1M and are neither mission critical to the university or designated by VITA as having statewide application.

  1. As the initial analysis is completed and the project selection is approved by IT PMO, in conjunction with the initiator and appropriate management approvers, will assign a final project categorization (High/Medium/Low) and outline more specifically the project management and documentation requirements to be fulfilled as the project proceeds. The specific requirements vary with project categorization.

Project Categorization

UMW IT projects are categorized as High, Medium or Low based on a variety of parameters including but not limited to budget, resources, time to complete and risk. An IT Project Categorization Matrix is used to evaluate and determine each projects category. The IT Project Categorization Matrix can be found at

Any activity that is determined by management to be undertaken as a project in one of these categories is covered by the Project Management Standard. The amount of oversight and documentation required is directly related to and increases with project complexity. The goal is to apply just the right amount of management control needed for a specific project to succeed.

Certain other characteristics may elevate the category for technology projects. These projects involve systems that:

  1. interface to the university’s Banner Administrative Systems (for date related to Student Administration, Finance, Human Resources, Advancement, Financial Aid, Student Accounts Receivable, etc);
  2. authenticate using the university’s directory services (i.e. Active Directory); or,
  3. access, transmit, process or store highly sensitive data such as Social Security Number (SSN).

Project Documentation by Categorization

MAJOR Greater than $1M

Project Research Form (PRF)/Project Approval Form (PAF)

Project Charter

Project Plan

  • Budget/Costs Plan
  • Resource Plan
  • Project Schedule
  • Communications Plan
  • Quality Management Plan
  • Procurement Management Plan
  • Risk Log

COV quarterly project status reports

Project Close Out report

NON-MAJOR Less than or equal to $1M       HIGH/MEDIUM

Project Research Form (PRF)/Project Approval Form (PAF)

Project Charter

Project Plan

  • Budget/Costs Plan
  • Resource Plan
  • Activity Schedule
  • Communications Plan
  • Quality Management Plan
  • Procurement Management Plan
  • Risk Log

Project status reports

Project Close Out report


Project Research Form (PRF)/Project Approval Form (PAF)

Activity Schedule (optional as determined by PM)

Project Close Out report



  • Projects over $2M require a Project Charter and are reviewed by VITA PMD before initiation.

Project Management Knowledge Areas

The project life cycle is comprised of phases: Initiating, Planning, Executing, Monitoring and Control, and Closing. In addition to these process groups, processes can also be classified into nine categories referred to as the Project Management Knowledge Areas. These Knowledge Areas combine and bring together processes that have characteristics in common. The level of project categorization is used to determine the required documentation associated with each of the nine Knowledge Areas and processes (reference Project Documentation by Categorization matrix).

The nine Knowledge Areas of Project Management are as follows:

  1. Project Integration Management: This process coordinates the other areas to work together throughout the project. The six processes associated with Project Integration Management involve identifying and defining the work of the project and combining and integrating the appropriate activities. This is the only Knowledge Area that contains processes across all five of the project management process groups. The processes within Project Integration are tightly linked, as they occur continuously throughout the project:
  • Develop Project Charter
  • Develop Project Management Plan
  • Direct and Manage Project Execution
  • Monitor and Control Project Work
  • Perform Integrated Change Control
  • Close Project
  1. Project Scope Management: The five processes of Project Scope Management are used to ensure that the project includes all of the requirements and no new requirements are added in a way that could harm the project.
  • Collect Requirements
  • Define Scope
  • Create WBS
  • Verify Scope
  • Control Scope
  1. Project Time Management: The Project Time Knowledge Area consists of six processes that help to ensure the project is completed on schedule.
  • Define Activities
  • Sequence Activities
  • Estimate Activity Resources
  • Estimate Activity Durations
  • Develop Schedule
  • Control Schedule
  1. Project Cost Management: The Project Cost Management Knowledge Area consists of three processes that monitor costs to ensure the project is completed within budget.
  • Estimate Costs
  • Determine Budgeting
  • Control Costs
  1. Project Quality Management: The Project Quality Management Knowledge Area consists of three processes.   These processes ensure that the project meets the requirements, or does what it is expected to do.
  • Plan Quality
  • Perform Quality Assurance
  • Perform Quality Control
  1. Project Human Resource Management: The Project Human Resource Management Knowledge Area consists of four processes. These processes organize, develop, and manage the project team.
  • Develop Human Resource Plan
  • Acquire Project Team
  • Develop Project Team
  • Manage Project Team
  1. Project Communications Management: The Project Communications Management Knowledge Area consists of five processes. These processes determine what information is needed, how that information will be sent and managed, and how project performance will be reported.
  • Identify Stakeholders
  • Plan Communications
  • Distribute Information
  • Manage Stakeholder Expectations
  • Report Performance

A good project manager spends up to 90 percent of their time communicating. Overall, much of the project manager’s work involves managing project communication.

  1. Project Risk Management: The Project Risk Management Knowledge Area consists of six processes involved in identifying, managing and controlling risk of a project.
  • Plan Risk Management
  • Identify Risks
  • Perform Qualitative Risk Analysis
  • Perform Quantitative Risk Analysis
  • Plan Risk Responses
  • Monitor and Control Risk

According to the PMBOK® Guide, a risk is an uncertain event or condition that has a positive or negative effect on a project objective. Every project has some level of uncertainty and, therefore, some level of risk. Keep in mind that a risk is different from an issue. A risk may or may not occur. But when a risk materializes and impacts the project, it becomes an issue that must be handled.

  1. Project Procurement Management: The Project Procurement Management Knowledge Area consists of four processes. These processes are used to acquire the materials and services needed to complete the project.
  • Plan Procurements
  • Conduct Procurements
  • Administer Procurements
  • Close Procurements


Project management activities begin at the Initiation Phase where a project has been approved by management with funding identified. It continues on through the remaining life cycle phases of Planning, Execution and Control, and Closeout. This PM standard addresses the governance and management of any IT activity that meets the definition of a project.

Project Lifecycle

The lifecycle of a project begins when a person or organization recognizes a business need or problem requiring a solution. Projects are NOT just a set of tasks to perform! A project is a process that produces a unique product or service which allows the organization to achieve a desired business goal.

All projects are reviewed and managed through a lifecycle of phases, Initiation, Planning, Execution and Control, and Closeout.

  Project Phase Key Activities Deliverables
  • Project Sponsor has developed and submitted a project research/project approval template to the Technology Portfolio Management Committee.
  • Project Sponsor secures funding via new budget initiative or internal resource
  • CIO and PMO assign an IT Project Manager
  • Agree to bring together the core team members and stakeholders
  • Assign a project manager and establish others’ roles and responsibilities
  • As much as possible, identify the resources needed, the cost estimates, and a broad timeline
  • CIO approves charter, project now approved to move forward with detailed planning


Project Research Form (PRF)/Project Approval Form (PAF)

Project Charter

  • Collect requirements as needed. Requirements include the quantified and documented needs and expectations of the sponsor, customer, and other stakeholders. Some options include, focus group sessions, stated stakeholder requirements, and surveys
  • Develop project scope by describing, in sufficient detail, the processes required to ensure that the project includes all the work required, and only the work required, to complete the project successfully.
  • Develop Work Breakdown Structure (WBS) and schedule. The WBS is a detailed, hierarchical list of the tasks to be executed by the project team to accomplish the project objectives and create the required deliverables.
  • Develop budget plan (including hard and soft costs)
  • Assign resources
  • Develop project schedule
  • Develop procurement plan (if applicable)
  • Develop quality management plan
  • Develop communications strategy
  • Assess and document risks and risk strategy
  • Submit project plan to PMO
  • File project plan on PMO SharePoint site
Project Plan
Execution and Control
  • Assemble the project team
  • Procure resources
  • Execute project tasks
  • Distribute information
  • Manage stakeholder expectations
  • Provide status reports
  • Monitor performance
  • Monitor progress according to the schedule
  • Monitor and log issues and risks
  • Manage procurement
  • Implement testing and training plans
Identified in the Project Plan
  • Formal acceptance of final deliverable(s) by the Project Sponsor
  • Sponsor and IT Project Manager complete close out report including lessons learned and file with IT PMO
  • Archive project documents in SharePoint
Close Out Report



The initiation process defines a new project and obtains authorization for that project to start. A project research form outlining the business justification for the project is prepared by the Project Sponsor. The sponsor serves as a “champion” for the project.

After the project research stage, a Project Approval form is submitted for review and approval by the Technology Portfolio Management Committee. Once approved, the project goes to the PMO, is appropriately classified, and the CIO and PMO will appoint an IT Project Manager. The Project Sponsor and Project Manager will identify the appropriate team members, and the Project Manager and project team will complete the project charter document.

Approval of the project charter by the CIO authorizes the Project Manager to staff the project team, procure resources, and oversee the people and resources necessary to complete the project. The project charter must be approved by the CIO before the project is considered approved for planning.


During the planning phase, information used in the Initiation phase is used to further refine the scope and define the objectives to be met by the project. The IT PMO will work with the Project Manager and team to identify documentation and project management activities that will be required (see the Project Documentation matrix for details). A project plan is developed, which includes the schedule, milestones, and plans for testing and training, security, procurement, resources, communication, and risks. The planning phase is complete when the project plan is completed and submitted to the CIO and PMO. With the submission and acceptance of all project planning documentation by the CIO and PMO, then and only then is the Project Manager given approval to officially activate the project and proceed to the Execution and Control phase i.e. begin project work, assemble project team, procure materials/equipment, etc.

Execution and Control

Executing begins when team members begin the actual work, as defined in the project plan, to complete the defined tasks and develop the deliverables. This includes building, developing and managing the project team; distributing relevant project information to stakeholders as planned; and managing stakeholders’ expectations to ensure their needs are met.

Monitoring and Controlling processes track, review and regulate the project’s progress toward meeting the performance objectives as defined in the project plan. These include, but are not limited to, ensuring changes to the plan are tracked and approved; that decisions, issues and risks are documented and appropriately addressed; that timely and accurate project status reports and other relevant information are communicated; and that testing and training activities proceed according to plan.

Project Closeout

When the Project Sponsor has accepted the project’s deliverables as complete and signed off on the project, the project manager initiates action to finalize the project and submits a final status report to the sponsor and the IT PMO. An archive of the project’s documents must be stored on SharePoint. The final deliverable is transferred to operations and support staff where it becomes part of the operational activities of the university.

Project Manager Selection and Training

Project Managers are selected and assigned to projects by the CIO in consultation with the IT PMO. The training and certification required depend on the project classification and level of experience required to manage the project.

For projects with High classification, a Project Management Institute (PMI) or Virginia Information

Technologies Agency (VITA) certified project manager is required or equivalent experience. For all other projects, a non‐certified project manager may be assigned. However, it is recommended that a certified project manager serve as a consultant on these projects.


Activity Schedule – the planned dates for performing schedule activities and the planned dates for meeting schedule milestones

Information Technology Project ‐a temporary effort undertaken by the university with the primary purpose of creating a unique information technology product or service. Temporary means that the project has a definite beginning and a definite end. Unique means that the technology product or service is different in some distinguishing way from all other products or services provided.

Maintenance, Enhancement or Refresh (MER) Activity – development, migration or upgrade activity undertaken as part of the normal, on-going operation of an information technology system and that is not of such significance to be considered a system replacement or major architectural change.

Project Charter – a document that provides the project manager with the authority to apply organizational resources to project activities.

Project Research Form (PRF) – a list of general information questions to be completed by the project initiator and submitted to IT PMO as the basis for preliminary discussion, analysis and possible project identification and classification.

Procurement Management Plan – the document that describes how procurement processes from developing procurement documentation through contract closure will be managed.

Project Management Office provides project methodology guidance and support for the university’s IT projects. The PMO maintains Project Management Institute (PMI) or Virginia Information Technologies Agency(VITA) certification.

Project Manager assigned by the CIO and PMO and responsible for managing the project on behalf of the sponsor. Approval of the project charter authorizes the Project Manager to staff the project team, procure resources, and oversee the people and resources necessary to meet the project objectives. Project managers are responsible for reporting project status, budget, schedule and issues to the project stakeholders and the IT PMO. Every IT project must have a designated Project Manager.

Project Plan – according to the Project Management Body of Knowledge (PMBOK), the project plan is: “…a formal, approved document used to guide both project execution and project control. The primary uses of the project plan are to document planning assumption and decisions, facilitate communication among stakeholders, and document approved scope, cost, and schedule baselines. A project plan may be summarized or detailed.” The project plan is the planning document, capturing the entire project end-to-end, covering all project phases, from initiation through planning, execution and closure.

Project Sponsor the individual, usually part of the senior management team, who makes the business case for the project. This individual has the authority and responsibility to define project goals, secure resources, and resolve organizational issues and conflicts. The sponsor approves and provides formal sign‐off of the project deliverables and closeout report.

Project Team comprised of the individuals responsible for completing the project tasks and objectives. The team members may be assigned to the project in a full or part‐time capacity, and may report directly or indirectly to the Project Manager.

Stakeholders persons or organizations that may be impacted, positively or negatively, by the execution or completion of a project. Stakeholders may be actively involved in project activities and may influence the project outcome and deliverables. The Project Sponsor and Project Manager are responsible for identifying all stakeholders at the start of a project.

Work Breakdown Structure (WBS) a deliverable-oriented hierarchical decomposition of the work to be executed by the project team to accomplish the project objectives and create the required deliverables. It organizes and defines the total scope of the project.



Project Management Institute. 2008. A Guide to the Project Management Body of Knowledge (PMBOK Guide), 4th ed. Newtown Square, PA: Project Management Institute.

Virginia Information Technologies Agency. 2013 Project Management Standard (CPM 301-01). Chester, VA: Commonwealth of Virginia.

Supporting Information



Responsible manager(s)  IT Project Management Office
Procedure administrator IT Project Management Office
Approving body Office of the CIO



This standard is reviewed annually by 1 July of each succeeding year.  The IT PMO or assigned designee will review the standards for accuracy and relevancy and make any necessary revisions or adjustments.

Document footers will be updated to include the date of the most revision.

The Change History matrix will be updated accordingly.

Any exceptions or changes to this process will be approved by the CIO.


Approved v1.0 March 26, 2014 by the Acting CIO

March 22, 2016: v2.0 revised and approved standard based on newly implemented Technology Portfolio Management process.

May 31, 2016: v2.1 document aligned with IT template.