UNIVERSITY OF GUELPH PROJECT MANAGEMENT FRAMEWORK

UNIVERSITY OF GUELPH PROJECT MANAGEMENT FRAMEWORK

Table of Contents Document Purpose:... 3 What is a Project?... 3 What is not a Project? (e.g. Operational Tasks)... 3 What is Project Management?... 4 What is a Project Manager?... 4 What is a Project Team?... 4 What is a Project Management Framework?... 5 What is a Successful Project?... 3 Project Categories... 5 Why Implement a Project Management Framework... 5 Project Management Life Cycle... 6 Initiation (Phase 1.0)... 7 Planning (Phase 2.0)... 9 Implementation (Phase 3.0)... 11 Closing (Phase 4.0)... 13 Appendix: 1.0... 15 Template Usage by Project Size... 15 Appendix 2.0... 17 Change Request Process... 17 Appendix 3.0... 19 Terms and Definitions... 19 Appendix 4.0... 22 Document Revision Log... 22 Appendix 5.0... 23 Document Ownership... 23 Appendix 6.0... 24 List of Document Reviewers... 24 Appendix 7.0... 25 Project Management Framework Approval and Sign-Off... 25 University of Guelph Project Management Framework» Page 2 of 25 «

Document Purpose: The purpose of this document is to introduce common Project related concepts as well as to formalize a repeatable, scalable and standardized approach to managing projects. This document will outline the following: What is a Project? What is Project Management? What is a Project Manager? What is a Project Team? What is a Project Management Framework? What is a Successful Project? Project Definitions Why does one need a Project Management Framework? Project Life Cycle Process Tools, templates, checklists necessary to support the Project Life Cycle Process What is a Project? A project is defined by the following parameters: A temporary endeavor undertaken to create a unique product, service or result against agreed to goals, objectives, requirements and specifications. It has a definitive START and a definitive END and is a time constrained effort. It provides a unique solution/deliverable to a need that has not existed in this form prior to this undertaking. Projects are different from other work because they conclude when their agreed to goals, objectives, requirements and specifications are achieved. Upon conclusion, the project deliverable(s) transitions into steady state operational support and is no longer considered a project. What is not a Project? (e.g. Operational Tasks) A minor enhancement to internal tools or process; A patch to an existing environment, due to a software bug; Involve day to day operational tasks performed by a single team; and It does not have a defined Start and End time constraint, budget or other agreed to project element(s). What is a Successful Project? A Project is successful if the following parameters are achieved: It meets the agreed to goals, objectives, requirements and specifications as defined by the Project Brief and/or the Project Charter and other supporting documentation; and It is completed in the agreed to timelines; It is completed within the agreed to budget. University of Guelph Project Management Framework» Page 3 of 25 «

What is Project Management? Project Management is the application of knowledge, skills, tools and techniques across a broad range of activities in order to meet the predetermined, agreed to goals, objectives, requirements and specifications of a particular project/endeavor. Project Management knowledge and practices are best described in terms of their component processes (hereto referred to as phases). 1 The University of Guelph will adhere to four Project Management phases. The phases are: 1. Initiation: The process where a need generates an idea for a piece of work that is discussed, refined and eventually goes through an approval process where it formally becomes a Project. 2. Planning: The process where the Project requirements, specifications and management plans are developed. 3. Implementation: The process where the Project requirements, specifications and management plans are executed on and monitored. 4. Closing: The process where the Project deliverables are approved (i.e. meet project goals, requirements, specifications) by the customer and the Project concludes. Each of these Phases has with them specific tools that support them. The associated tools and which phase to use them are outlined in Appendix 1.0. What is a Project Manager? A Project Manager (PM) is a person given the authority to manage the day to day aspects of a project. The PM is responsible for the successful implementation of the four Project Management Phases as outlined within this document. What is a Project Team? A Project Team is a group of people, within or outside your own specific work team, selected to work together (on a full or part time basis) in order to deliver the project s product/outcome according to the agreed upon goals, objectives, requirements and specifications. Project Team members are responsible for understanding the work they need to complete, completing their assigned work within agreed to parameters (time/cost/quality), informing the PM of issues, scope changes, risks and quality concerns. The PM works collaboratively with Project Team members and other resources to complete the assigned initiative or task. Project Team members are to proactively communicate status and assist their PM in managing Client and Project Sponsor expectations. 1 Source: http://www.pmi.org/projectmanagement/project.htm University of Guelph Project Management Framework» Page 4 of 25 «

What is a Project Management Framework? A Project Management Framework (PMF) is a tool kit containing the processes, tools and templates a PM needs to implement and draw from in order to support consistent project communication (with the Client, the end user group(s) and the Project Team members) and the successful delivery of a project. The framework will enable PMs to better control project processes on future initiatives. The PMF defined in this document is a scalable tool kit that works for projects of varying sizes. It is a framework using best practices but more lightweight than many formal project management methodologies. Project Categories Projects come in all shapes and sizes. This particular framework will utilize three different project categories: Small, Medium and Large. Your Management Team reviews the details of the opportunity, determines and approves which of the three project categories (also referred to as sizes) the opportunity falls within. The following table specifies the high level parameters used to categorize Project sizes, however other factors will also be considered such as risk factors, visibility, involvement of clients, potential impact to large groups. Small Project Parameters Medium Project Parameters Large Project Parameters Less than or equal to 15 FTE days Greater than 15 FTE days but less Greater than 30 FTE days and no more than 3 project team than or equal to 30 FTE days (FTE=Full Time Equivalent) participants Guideline only. Categorization of Project size is at the discretion of the Management Team Why Implement a Project Management Framework A PMF formalizes the approach to Project Management with the development and implementation of key processes and practices. For this initial effort, the focus of the PMF is on the definition of Project Management processes. The processes will act as an introduction to a formal Project Management environment that is sustainable and scalable. A more robust and comprehensive PMF can be developed as the Project Management environment evolves. The goal of implementing a PMF is to: Increase process consistency and efficiency in the delivery of Small, Medium and Large projects; Increase capacity and support resource management, both budgetary and people; Help to ensure project deliverables achieve the agreed to goals, objectives, requirements and specifications of requests regardless of their origin; Increased satisfaction by improving communications and managing expectations; Assure appropriate ownership of process results; and Ensure that all staff (your own team and Client(s)) is aware of the resource commitments on existing projects and future initiatives. University of Guelph Project Management Framework» Page 5 of 25 «

Project Management Life Cycle Regardless of project category (Small, Medium, Large), in order to increase the consistency and efficiency of projects, all projects should follow a routine set of standard processes. These standard processes together become a Project Management Life Cycle. By following these standard processes, your ability to repeatedly deliver successful project implementations is increased. The following process flowchart represents the four Phases of the Project Management Life Cycle. PM Life Cycle processes apply to all Small, Medium and Large projects. The four Phases of the Project Management Life Cycle are: 1. Initiation; 2. Planning; 3. Implementation; and 4. Closing. The key to the Project Management Framework is that it is a process with associated tools and templates that can easily be scaled (up or down) and implemented across all projects regardless of project size or Client area. Project Management Life Cycle Diagram University of Guelph Project Management Framework» Page 6 of 25 «

Initiation (Phase 1.0) The first Phase of Project Management deals with determining what projects will be performed as well as preparing preliminary documents that validate the decision to move forward with the project. The following is a pictorial representation of the Initiation Process as well as a discussion of the critical activities/tasks performed during this first project Phase. Projects may be initiated from either within your own team or requested from other departments. University of Guelph Project Management Framework» Page 7 of 25 «

1.1 Review Project Opportunities: Prior to Phase 1, there has most likely been some initial discussion(s) about a need faced by a member of your team and/or the Client. These conversations are typically had with the person who ultimately becomes the Project Sponsor (defined in Appendix 3.0). The first task of the Initiation Phase calls for the internal review and discussion of each project opportunity/need. This initial review can occur at the Team level and with the reporting Manager; however it could involve input from other Teams, Clients and/or other Management Teams. All projects should be reviewed taking into consideration the project s alignment with the objectives of your team, the Client and/or the University of Guelph as a whole. If satisfied that a project opportunity/need exists, take the project proposal to your Manager for approval to develop a Project Brief. 1.2 Develop Project Brief: Once the project has been initially reviewed and identified as a Project opportunity, a Project Brief is developed. This may or may not be performed by the individual who raised the initial opportunity/need. The Project Brief will contain pertinent information about the project opportunity including the estimated size, in order to facilitate the project selection and approval. See 1.1 Project Brief Template.doc for a suggested template of this document. 1.3 Project Brief Reviewed by Management: Management reviews the Project Brief and approves both the size and scope of the Project. In the event that the project requires resources from other Teams, the Manager will communicate as necessary to all appropriate parties to ensure agreement on participation, approval and/or Project Brief rejection. For all approved/accepted Project Briefs Management will determine prioritization of the project in accordance with other projects. 1.4 Appoint Project Manager: Once Management has approved the Project, the Project Manager (PM) is assigned to carry the Project forward through the remaining Project Life Cycle processes. The first responsibility of the newly assigned PM is to create and issue the Project Charter (where the Project size is Large ), or, amend the Project Brief (where the Project size is Small or Medium ). 1.5 Develop Project Charter or Move Project Brief Forward: The Project Charter (See 1.2 Project Charter Template.doc for a suggested template of this document) is a critical component of the Project as it formally documents the goals, objectives, scope, milestones, and management/client commitment to the project. Depending on the size, scope and complexity of the project, the Project Brief may serve as the Project Charter. Where the Project Brief takes the place of the Project Charter (i.e. Small and Medium Projects), the brief template will be carried forward for approval by the Project Sponsor. 1.6 Formal Approval to Proceed: Formal approval to proceed with the project occurs when the Project Charter (or where applicable the Project Brief) is reviewed and officially signed off by (at minimum) the Project Sponsor /Client and your Manager. Once formal approval is received, project priority is confirmed, funding is approved and project start dates are scheduled. At this point the project is given the green light to proceed according to schedule. Formal Approval to Proceed is a significant step in the overall Project Life Cycle process and is considered a Milestone when achieved. University of Guelph Project Management Framework» Page 8 of 25 «

Planning (Phase 2.0) Planning or Phase 2 is characterized by the formation of the Project Team, the development of detailed requirements, specifications and the development of Project Management Plans. Planning activities in most cases commence during or immediately after the 1.6 Formal Approval to Proceed process step and can be completed in parallel with the formation of the Project Team and the documentation of detailed requirements and specifications. Phase 2.0 activities are characterized in the following diagram and discussed below: University of Guelph Project Management Framework» Page 9 of 25 «

2.1 Kick off the Project: Once the Project gains formal approval to proceed by Management and the Client (if applicable), the cross functional Management Team (your Manager and Client) assigns the necessary human resources to the project. The PM brings all necessary Project Team members together for the first time to Kick off the project formally (see 2.1 Project Kick Off Presentation Template.ppt for a suggested template of this presentation). At the Kick off meeting, the PM communicates the goals, objectives, scope and high level timelines of the project as well as the roles and responsibilities of each of the Team Members. 2.2 Document Functional and Technical Specifications: Once the team has formally banded at the time of the Project Kick off, the necessary subset of the team begin to uncover and document the detailed functional and technical requirements and specifications of the project deliverable(s). These requirements and specifications are intended to identify how to build a process/system that meets the goals, objectives, scope and high level requirements agreed to in the Project Brief and/or the Project Charter. Functional Requirements may include process flow, mocked screen shots, security requirements, and table values. The PMF does not provide templates to gather Document Requirements and Technical Specifications. These are unique to each project. In the event that outof scope requests are made, then the requests are assessed for level of effort/cost and reviewed with the Project Sponsor/Client. Refer to Appendix 2.0 to review the Change Request process. 2.3 Approve Functional and Technical Specifications: The development of detailed functional and technical requirements and specifications is an iterative process. In the end, the final requirements and specifications which are in line with the project scope as agreed to in the Project Brief and/or the Project Charter are signed off by the Project Sponsor or Client prior to their Implementation/Execution (described in Phase 3.0 Implementation). Approve Functional and Technical Specifications is a significant step in the overall Project Life Cycle process and is considered a Milestone when achieved (see 2.2 Functional Requirements and Technical Specifications Signoff.doc for a suggested template of this document). In the event that out of scope requests are made at this stage, please refer to Appendix 2.0, Change Request Process. 2.4 Develop Project Management Plans: The PM will prepare a number of Project Management Plans using the PMF monitoring and tracking templates. (See Appendix 1.0, Templates 2.3 2.11). In the event, that external resources are required, the PM is required to implement the already established RFP (Request for Proposal) / RFQ (Request for Quote) process (living outside of the PMF). Prior to implementing the Project Management Plans, the Project Team reviews them with the PM. Under the advisement of the Project Sponsor, revisions can be made as required throughout the duration of the project until closing. 2.5 Approve Project Management Plans: Once the final iterations of the initial Project Management Plans are complete, the PM seeks approval from the Project Sponsor (see 2.12 Project Plan Signoff.doc for a suggested template of this document). Approve Project Management Plans is a significant step in the overall Project Life Cycle process and is considered a Milestone when achieved. University of Guelph Project Management Framework» Page 10 of 25 «

Implementation (Phase 3.0) The Implementation Phase involves performing the technical/process work needed to achieve the project s objectives, testing of the final deliverables and executing against the overall Project Management Plans that were created in Phase 2.0. The Implementation Phase is iterative. The diagram below depicts the overall implementation process as linear; however in practice it is iterative. Development of project deliverables, at times occur in parallel with requirements and specifications revisions and Project Management Plan updates. The following is a pictorial representation of Phase 3.0 including a description of each activity contained within the process: University of Guelph Project Management Framework» Page 11 of 25 «

3.1 Ongoing Controlling, Monitoring & Project Tracking: Along with monitoring and managing the overall Project Management Plans, the PM takes corrective actions where necessary to realign the Project to the approved plans. Controlling, Monitoring and Tracking includes the ongoing management of time, budget, quality, change requests, change control (those changes affecting project scope), risk assessment and issue management as well as updating and amending all project documentation as necessary (Appendix 1.0, Templates 2.3 2.11). Key areas of monitoring, managing and controlling are: Manage Client Satisfaction: The PM and the Project Team manage Client satisfaction by setting their expectations and keeping them involved and informed of project progress and decisions per the Communication Plan. Manage Implementation of Requirements and Specifications: The PM monitors implementation and final testing of the requirements and specifications as well as enduser training throughout the duration to ensure adherence to the overall Project Management Plans. Manage Project Documentation: The PM manages the ongoing creation, revision and distribution of all Project Management Plans, requirements and specifications documentation. Any changes to documentation that impact project related to time, cost or deliverables will require formal signoff (see 3.1 Document Amendment Sign off.doc for a suggested template of this document). 3.2 Roll Out Complete: The completion of the Implementation Phase is marked by the delivery of the final product. Roll Out Complete is a significant milestone that signifies that the technical piece of the implementation is complete and the deliverable is ready for final User Acceptance Testing (UAT). Roll Out completion includes the execution and successful completion of internal Team testing against agreed to technical requirements and technical specifications. 3.3 UAT Complete: The final step during Phase 3.0 is successful completion of User Acceptance Testing (UAT). UAT is intended to ensure and demonstrate that the agreed to functional requirements and specifications have been achieved by the project. UAT completion triggers the delivery of end user training where necessary. University of Guelph Project Management Framework» Page 12 of 25 «

Closing (Phase 4.0) The final Project Management Phase ensures a smooth and distinct wrap up of project processes and activities for both the Project Team and the Client. The following is a pictorial representation and description of the Phase 4 activities: University of Guelph Project Management Framework» Page 13 of 25 «

4.1 Transition to Steady State/Operational Support: Once the deliverable of the project is complete (including all testing and training), the product is transitioned to any applicable Team(s) for ongoing support. Transition/knowledge transfer on the product is completed by the Project Team SME(s) (see Appendix 3.0 Terms and Definitions). Once the knowledge transfer is complete, the final product is considered steady state and in full operational support. 4.2 Client Acceptance: At this stage, UAT is successfully complete (where necessary signed off) as is knowledge transfer. The PM advises, the Client/Project Sponsor that the project has successfully concluded. The PM reviews with the Client/Project Sponsor, the Project Deliverable Checklist to demonstrate that the final product has met the goals and objectives of the project (see 4.1 Project Deliverable Checklist.doc for a suggested template of this document). Where applicable, the PM develops and reviews any Service Level Agreements (SLAs) with the Client/Project Sponsor. Formal Client/Project Sponsor sign off on the Project Deliverable Checklist and SLAs is received (see 4.2 Client Sponsor Sign off.doc for a suggested template of this document). Client Acceptance is a significant step in the overall Project Life Cycle process and is considered a Milestone when achieved. 4.3 Release Project Team: Project Team members participate in a Lessons Learned meeting (see 4.3 Lessons Learned.doc for a suggested template of this document). They are then released from their project related duties. Groups and individuals should be recognized for their accomplishments. 4.4 Compilation and Filing of Final Project Documentation: Materials and documentation developed and maintained during the project (deliverables, designs, progress reports, project plans, meeting minutes and lessons learned) are compiled and saved either in a hard copy project binder or as a set of electronic project documents, preferably on a shared file system for others to view. University of Guelph Project Management Framework» Page 14 of 25 «

Appendix: 1.0 Template Usage by Project Size The following table outlines the templates that make up the PMF separated by Project Management Life Cycle Phase. X denotes the minimum template requirements by project size. The use of any template above the required minimum is left to the discretion of the PM. The use and implementation of these templates are not limited to the Phase that they are associated to within this matrix. Although the templates are listed by Project Phase, they are created, managed and updated throughout the course of the project. They do not reflect any modifications, adaptations that may be required during the life of the project, for example to suit a specific Team s needs. The Time Bound Task List should be modified to best represent and manage their task level requirements and milestones. They as well do not preclude the PM from making use of available automated tools for use of gathering same data. Project Phase / Template Template ID Small Project Medium Project Large Project 1.0 INITIATION 2.0 PLANNING Project Brief 1.1 X X X Project Charter 1.2 X Project Kick Off Presentation 2.1 X X Functional Requirements and Technical Specifications Sign Off Form Project Documentation and Planning Checklist 2.2 X X 2.3 X X Budget 2.4 X Change Request Log 2.5 X X Communication Plan 2.6 X X X Issue Management Log 2.7 X X Project Status Report 2.8 X X Risk Management Log 2.9 X Status Meeting Action Items and Decisions 2.10 X X Time Bound Task List 2.11 X X X Project Plan Sign Off 2.12 X X University of Guelph Project Management Framework» Page 15 of 25 «

3.0 IMPLEMENTATION (INCLUDES MANAGEMENT OF TEMPLATES CREATED IN 2.0) Document Amendment Sign Off 3.1 X X 4.0 CLOSING Project Deliverable Checklist 4.1 X X X Client Sponsor Acceptance Sign off 4.2 X X X Lessons Learned 4.3 X X Note: For Small Projects approvals can be received by electronically. University of Guelph Project Management Framework» Page 16 of 25 «

Appendix 2.0 Change Request Process It is inevitable that change requests will be made during the life of any Small, Medium or Large Project. Without due process, change can derail a project. Change Requests can occur during any one of the four Project Management Life Cycle Phases. Therefore, it is CRITICALLY important to manage change requests appropriately so that they do not negatively impact your Project. Small Projects do not require formal document amendment sign off/approvals. Whereas Medium and Large Projects require a Change Request Log (see 2.5 Change Request Log Template.xls for a suggested template of this document). All changes made to the approved project related to time, cost, deliverables, requirements and/or specifications documentation will require documentation changes and Project Sponsor approval. Use the Document Amendment Sign off to reflect such (see 3.1 Document Amendment Sign Off.doc for a suggested template of this document). The following is a pictorial representation and description of the activities to follow during the Change Request process. University of Guelph Project Management Framework» Page 17 of 25 «

University of Guelph Project Management Framework» Page 18 of 25 «

Appendix 3.0 Terms and Definitions Term Project Project Brief Project Charter Project Management Project Management Life Cycle Definition A temporary endeavor undertaken to create a unique product, service or result against agreed to goals, objectives, requirements and specifications. It has a definitive START and a definitive END and is a time constrained effort. It provides a unique solution/deliverable to a need that has not existed in this form prior to this undertaking. Projects are different from other work because they conclude when their agreed to goals, objectives, requirements and specifications are achieved. Upon conclusion, the project deliverable(s) transitions into steady state operational support and is no longer considered a project. A Project Brief is a high level summary documenting a project opportunity. A Project Brief is made up of the key pieces of information necessary for Management to determine if the opportunity has enough merit to be deemed a project. A Project Charter is a statement of the scope, objectives and participants in a project. It provides a preliminary delineation of roles and responsibilities, outlines the project objectives, identifies the main stakeholders, and defines the authority of the project manager. Approval of the Project Charter is the signal that the Project Manager can move forward with the Planning phase of the project. Project Management is the application of knowledge, skills, tools and techniques across a broad range of activities in order to meet the predetermined, agreed to goals, objectives, requirements and specifications of a particular project/endeavour. The Project Management Life Cycle is a set of standard processes that are followed through the duration of a project. The processes within the context of this framework are called Phases. The four project management life cycle phases are Initiation, Planning, Implementation and Closing. University of Guelph Project Management Framework» Page 19 of 25 «

Term Project Management Framework Project Manager Project Sponsor Definition A Project Management Framework (PMF) is a tool kit containing the processes, tools and templates a Project Manager needs to implement and draw from in order to support consistent communication between users and team members and the successful delivery of a project. The PMF is a scalable tool kit that works for small, medium and large projects. A Project Manager (PM) is a person given the authority to manage a project. The PM is responsible for the successful implementation of the four Project Management Phases. A Project Sponsor is the person that is ultimately responsible for the project. This role can be held within your own Team or with an external Client group. Ideally, this role is held by someone in senior management. Typically, the Project Sponsor is responsible for: Championing the project; Obtaining budget approval for the project; Accepting responsibility for problems escalated by the PM; Signing off documents such as the Project Brief and Project Charter; and Overcoming any organizational resistance to the project. Project Team Subject Matter Expert (SME) Client A Project Team is a group of people selected to work together (on a full or part time basis) in order to deliver the project s product/outcome according to the agreed upon goals, objectives, requirements and specifications. Project Team members are responsible for understanding the work that they need to complete, completing their assigned work within agreed to parameters (time/cost/quality) informing the PM of issues, scope changes, risks and quality concerns. Project Team members are to proactively communicate status and assist their PM in managing expectations. A Subject Matter Expert is an individual who understands a business process and/or technology area well enough to answer questions and/or direct and participate in functional requirement and technical specification documentation development and implementation. A client is the individual/group that is receiving the result of the project. The client can participate in the project as an SME. The Client can be within or external to your team. University of Guelph Project Management Framework» Page 20 of 25 «

Term Stakeholder Goal Objective Milestone Functional Requirements Technical Specifications Definition A Stakeholder is someone who has a stake or interest in the outcome of the project and/or is affected by the project. A goal is the desired end state that a Project is intended to achieve and that (when achieved) terminates behavior intended to achieve it. An objective is the articulation of the sub components that are necessary to be achieved in order to reach the desired end result/goal of a project. A milestone is a terminal element that marks the completion of a work package or phase, typically marked by a high level event such as completion, endorsement or signing of a deliverable, document or a high level review meeting. Information related to how a product and/or system is intended to behave/work from the perspective of the end user. Information related to how the product and/or system is to be developed from a technology perspective, looking at the system requirements, hardware/infrastructure, software code and platform development. University of Guelph Project Management Framework» Page 21 of 25 «

Appendix 4.0 Document Revision Log The following table documents any changes and/or updates made to this document once the initial draft has been completed. Doc Version # Revision Date 1.0 January 09, 2009 Name of Reviser Section /Page Rationale for Change Kent Hoeg All Development of PMF Document (revised from CCS version) Revision University of Guelph Project Management Framework» Page 22 of 25 «

Appendix 5.0 Document Ownership The following table documents the final ownership of this document upon its completion and approval. Once the document is transitioned, it is the responsibility of the Document Owner to update and maintain the relevance of the document on an ongoing basis. Document Owner Role/Department Transition Date <Place your name here> University of Guelph Project Management Framework» Page 23 of 25 «

Appendix 6.0 List of Document Reviewers Name of Reviewer Title Reviewer Responsibility Place the names of all reviewers who should approve changes to this document or receive copies of this document, if changed. University of Guelph Project Management Framework» Page 24 of 25 «

Appendix 7.0 Project Management Framework Approval and Sign Off Once the Project Management Framework has been adopted by a Department/Faculty, this document is signed off by a senior executive of the Department/Faculty. This creates ownership within the process and shows support for the framework throughout the department. Any changes and/or updates to the Project Management Framework required after it has been approved will be documented in Appendix 4.0 and will require this document to be approved/signed again. Based upon my input and review of the information contained within this document, I approve of the scope and content contained within the Project Management Framework. We adopt this Project Manage Framework to be utilized by our department. <Enter First Name/Last Name> <Title> <Department/Faculty> University of Guelph Signature Date (DD/MM/YYYY) University of Guelph Project Management Framework» Page 25 of 25 «