Project Management Framework Handbook

Project Management Handbook(A Framework)

frame·work (plural frame·works)

“underlying set of ideas: a set of ideas, principles, agreements, or rules that provides the basis or outline for something intended to be more fully developed at a later stage (e.g., providing a framework for next week's discussions).”

-- MSN Encarta Dictionary

Prepared By

Document Owner(s) Project / Organization Role

Andy Novak EPM System Manager / PMO Manager

Project Management Handbook Version Control

Version Date Author Change Description

1.0 5/22/07 Andy Novak Draft Completed

2.0 8/16/07 Andy Novak Final Draft

3.0 12/12/07 Andy Novak Review Gate Changes

4.0 2/08/2008 Maurice Leatherbury

Added stage gate approval policy, table of required data elements for each size project, general edits for conformance to UNT’s project management policy

4.1 2/11/2008 Andy Novak Final changes per Charlotte Russell and Andy Novak

UNT Project Management Handbook

TABLE OF CONTENTS

1 INTRODUCTION..................................................................................................................... 5

1.1 Overview....................................................................................................................5

1.2 Structure..................................................................................................................... 6

1.3 Purpose...................................................................................................................... 7

1.4 Project Approval Structure..........................................................................................7

1.5 Project Classification and Level of Project Detail........................................................8

1.6 Organization...............................................................................................................8

2 BUSINESS JUSTIFICATION / INITIATION REVIEW GATE..................................................9

2.1 Overview....................................................................................................................9

2.2 Critical Success Factors.............................................................................................9

2.3 Activities...................................................................................................................102.3.1 Define Business Need / Opportunity.........................................................................102.3.2 Define Business Objectives and Benefits.................................................................102.3.3 Define Project Objectives.........................................................................................112.3.4 Identify Project Manager...........................................................................................122.3.5 Identify Sponsor........................................................................................................132.3.6 Ensure Alignment with Strategic Direction................................................................132.3.7 Define Project Scope................................................................................................142.3.8 Develop Preliminary Budget and Milestones............................................................142.3.9 Identify Project Constraints and Assumptions..........................................................152.3.10 Develop Project Organization (Governance)............................................................152.3.11 Identify and Engage Key Stakeholders.....................................................................162.3.12 Perform Initial Risk Evaluation..................................................................................16

2.4 Deliverables..............................................................................................................172.4.1 Project Plan..............................................................................................................172.4.2 Project Charter.........................................................................................................172.4.3 Sign-Offs..................................................................................................................17

3 PLANNING REVIEW GATE..................................................................................................18

3.1 Overview.................................................................................................................. 18

3.2 Critical Success Factors...........................................................................................19

3.3 Activities...................................................................................................................203.3.1 Develop Product Scope Statement...........................................................................203.3.2 Develop Procurement Plan.......................................................................................203.3.3 Develop Resource Plan............................................................................................213.3.4 Create Schedule.......................................................................................................22

4/11/2023


3.3.5 Refine Project Budget...............................................................................................233.3.6 Perform Risk Assessment........................................................................................243.3.7 Develop Organizational Change Mgt Plan................................................................243.3.8 Develop Quality Management Plan..........................................................................243.3.9 Develop Communication Plan..................................................................................25

3.4 Deliverables..............................................................................................................263.4.1 Project Plan..............................................................................................................263.4.2 Sign-Off....................................................................................................................26

4 SOLICITATION AND CONTRACTING REVIEW GATE (MAJOR PROJECTS ONLY).......27

4.1 Overview.................................................................................................................. 27

4.2 Activities...................................................................................................................274.2.1 Deliverables..............................................................................................................274.2.2 Sign-Off....................................................................................................................27

5 IMPLEMENTATION REVIEW GATE....................................................................................28

5.1 Overview.................................................................................................................. 28


5.3 Activities...................................................................................................................305.3.1 Execute Procurement Plan.......................................................................................305.3.2 Manage Schedule.....................................................................................................305.3.3 Document Work Results...........................................................................................315.3.4 Manage Quality........................................................................................................325.3.5 Manage Costs..........................................................................................................325.3.6 Manage Risks...........................................................................................................335.3.7 Manage Issues.........................................................................................................355.3.8 Manage Scope.........................................................................................................365.3.9 Manage Organizational Change...............................................................................375.3.10 Communicate Information........................................................................................375.3.11 Conduct Status Review Meetings.............................................................................385.3.12 Review Project Checkpoints.....................................................................................395.3.13 Administer Contracts / Vendors................................................................................395.3.14 Update Project Planning Documents........................................................................40

5.4 Deliverables..............................................................................................................415.4.1 (Formal) Project Status Reports...............................................................................415.4.2 Updated Planning Documents..................................................................................415.4.3 Project-Specific Deliverables....................................................................................415.4.4 Sign-Off....................................................................................................................41

6 BENEFITS REALIZATION / CLOSEOUT REVIEW GATE...................................................42

6.1 Overview.................................................................................................................. 42


6.3 Activities...................................................................................................................436.3.1 Conduct Business Outcomes Review Meeting.........................................................43

4/11/2023


6.3.2 Conduct Lessons Learned Meeting..........................................................................436.3.3 Conduct Contract Closure........................................................................................446.3.4 Conduct Knowledge Transfer...................................................................................45

6.4 Deliverables..............................................................................................................466.4.1 Business Outcomes Review Document....................................................................466.4.2 Lessons Learned Report..........................................................................................466.4.3 Sign-Off....................................................................................................................46

7 KEY ROLES AND RESPONSIBILITIES...............................................................................47

7.1 Overview.................................................................................................................. 47

7.2 Sponsor....................................................................................................................487.2.1 General Functions....................................................................................................487.2.2 Business Justification/Initiation Review Gate...........................................................487.2.3 Planning Review Gate..............................................................................................487.2.4 Implementation Review Gate...................................................................................487.2.5 Benefits Realization/Closeout Review Gate.............................................................48

7.3 Project Manager.......................................................................................................497.3.1 Overview.................................................................................................................. 497.3.2 General Functions....................................................................................................497.3.3 Business Justification/Initiation Review Gate...........................................................497.3.4 Planning Review Gate..............................................................................................497.3.5 Implementation Review Gate...................................................................................497.3.6 Benefits Realization/Closeout Review Gate.............................................................50

7.4 Steering Committee..................................................................................................517.4.1 Overview.................................................................................................................. 517.4.2 General Functions....................................................................................................517.4.3 Business Justification/Initiation Review Gate...........................................................517.4.4 Planning Review Gate..............................................................................................517.4.5 Implementation Review Gate...................................................................................517.4.6 Benefits Realization/Closeout Review Gate.............................................................51

7.5 Project Team............................................................................................................527.5.1 Overview.................................................................................................................. 527.5.2 General Functions....................................................................................................527.5.3 Business Justification/Initiation Review Gate...........................................................527.5.4 Planning Review Gate..............................................................................................527.5.5 Implementation Review Gate...................................................................................527.5.6 Benefits Realization/Closeout Review Gate.............................................................52

8 APPENDIX A – PROJECT APPROVAL STRUCTURE........................................................53

9 APPENDIX B – PROJECT CLASSIFICATIONS...................................................................54

4/11/2023


1 INTRODUCTION

1.1 Overview

Texas Administrative Code (TAC), chapter 216 requires that public institutions of higher education in the state have a policy that communicates an institution-wide approach to project management practices and that those institutions manage information technology practices in a manner that includes documented and repeatable methods that the university uses to apply knowledge, skills, tools, and techniques to satisfy project activity requirements. UNT Policy xx.x meets that requirement and the policy refers to the Project Management Handbook (this document) for specific implementation details on project management practices that meet the policy’s requirements.

The Project Management Handbook is designed to meet the needs of all segments of UNT as technical information technology (IT) project work is performed. It serves as a guide to project teams as they plan the work, to management as they supply the required oversight, and to customers as they collaborate in the design and delivery of new products.

The Project Management Handbook is designed to be conceptually consistent with the Texas Department of Information Resources (DIR) Project Delivery Framework as well as with the Project Management Institute’s (PMI) A Guide to Project Management Body of Knowledge (PMBOK).

The Project Management Handbook applies to projects of the various sizes defined in the Project Management Policy, prescribing different levels of rigor depending on effort, complexity, etc. (see Appendix B). The Handbook does not contain specific procedures and forms that must be filled out for the various sizes of projects but gives an overview of the project management process at UNT.

The Computing and Information Technology Center (CITC) uses Microsoft’s Project Server and Project Portfolio Server to document and manage both the details of projects (Project Server) and the information about proposed and ongoing projects (Project Portfolio Server) Other departments may use simple paper forms to manage their projects as long as they conform to the requirements outlined in the Project Management Policy and this handbook.

The Handbook is applicable to all organizations on campus that implement IT projects (TAC 216 requires that the Policy cover the whole enterprise) but because the Computing and Information Technology Center conducts the vast majority of IT projects on campus, the Handbook is directed more clearly to the needs of the CITC for its project management. The CITC will assist departments outside of the CITC in meeting the planning and management requirements of IT projects upon request.

4/11/2023

http://info.sos.state.tx.us/pls/pub/readtac$ext.ViewTAC?tac_view=4&ti=1&pt=10&ch=216


1.2 Structure

The Project Management Handbook describes a set of activities and processes that for developing projects in a standard, consistent manner and a mechanism to obtain approvals at “review gates” along the way. The project management framework upon which the Handbook is built is broken down into five separate and distinct project phases :

1. Business Justification/Initiation2. Project Planning3. Soliciting and Contracting4. Project Implementation5. Benefits Realization/Closeout

The third of these phases, Soliciting and Contracting, is invoked only when the project being planned is defined as a major IT project under TAC 216. However, some of the elements required to solicit vendors and develop contracts are included in other phases.

4/11/2023


1.3 Purpose

Project management is the formal definition and approvals “wrapper” that ensures projects are executed as carefully as possible. The end goals are the empowerment of staff, enhanced team communication and collaboration, less rework, more predictable and consistent delivery of services, and increased customer satisfaction.

This document describes the processes that CITC uses during the various phases of technology projects. The reader will find a detailed description of the framework, as well as references deliverables and tools that are used in support of the framework.

Please note this document is not intended for use as an instruction manual for producing the deliverables at the end of each project phase. The objective is to present an overview of the key activities pertaining to the framework (i.e., the “What” vs. the “How”). Please refer to specific templates and Enterprise Project Management (EPM) System User Guides for step-by-step instructions.

The framework embedded in the Handbook is designed to reach the following goals:

Provide a common point of reference and a common vocabulary for talking and writing about the practice of project management for technology projects on campus.

Increase the awareness and professionalism of good project management practice among those charged with the responsibilities defined in the framework.

Define the roles of the sponsor, project manager, stakeholders, etc. and obtain consensus about their importance to project success.

Define the major approval processes at the various stages of a project, including the specification of who is responsible for/authorized to approve the progression from one stage of a project to the next stage.

Specify the level of detail and specificity that each size project must include in order to conform to the Project Management Policy. Because one of the underlying assumptions about project classification is that the level of detail about a project should correspond to the risks, costs, and possible benefits of the project, it is necessary that the Handbook tell the persons involved in a project the expectations of the project management process for that size project.

Create the basis for a collaborative environment where everyone engaged in technical project work understands what is required of them and why those requirements are key factors for improving project results.

1.4 Project Approval Structure

The final procedure of each of the review gates mentioned earlier is the approval (or disapproval) to proceed to the next stage of a project. Because some projects carry higher risks and/or higher costs to the university, those projects require final approval from administrators higher in the university’s chain of command. Appendix A details the approval structure for projects at UNT.

4/11/2023


1.5 Project Classification and Level of Project Detail

As noted earlier, larger projects require more documentation about the risks, costs, opportunities, etc. than small projects. Appendix B details which project “artifacts” (documents, forms, data elements, etc.) are required for each project classification.

1.6 Organization

Each Project Phase section of the document is organized as follows:

Overview / Description Critical Success Factors Activities Deliverables

4/11/2023


2 BUSINESS JUSTIFICATION / INITIATION REVIEW GATE

2.1 Overview

The Business Justification/Initiation Review Gate is the first stage of any project since it represents the identification of a need, the gathering of data about the scope and costs of meeting that need, and designing the management structure to perform the project. During this stage, the project request is approved for inclusion in the appropriate project portfolio (i.e., project list / “pipeline”).

Once it has been determined to be a priority item and there appears to be ample capacity available to perform the work, the project is further defined via varying components of a Full Business Case / Project Charter (depending on project size), evaluated, funded, and given final authorization to proceed (there may be a “gap” between the time the request is approved and the project is actually executed). This process works best when information about the project is documented and reviewed in a formal manner.

Development of a Project Charter promotes an early collaboration between the performing IT group (typically the CITC) and its customers. Early establishment of a good rapport among the players can help ensure a cooperative spirit later in the project.

A well-written Project Charter can help everyone involved understand and come to agreement on exactly what is being proposed, the benefits that can be expected, the technical approach to be taken and how the project’s deliverables will fit into ongoing operations.

2.2 Critical Success Factors

The project is feasible Identification of the Sponsor Formal acceptance by the Sponsor of responsibility to support the project Acceptance of the Project Charter Alignment with UNT strategic direction

4/11/2023


2.3 Activities

The following is a list of key activities necessary for successful initiation of a project and the creation of a Project Charter:

2.3.1 Define Business Need / Opportunity

The statement of need / opportunity should explain, in business terms, how the project will address specific needs or opportunities. Typically, satisfaction of a need or opportunity will provide specific benefit to UNT, e.g.:

Keep an existing service or operation in good working order Improve the efficiency or effectiveness of a service Provide a new service as mandated by an external authority Obtain access to needed information that is not currently available Reduce the cost of operations

The discussion of the need / opportunity should provide an understanding of:

Origin of the need, or how the opportunity was recognized The magnitude of the need / opportunity Contributing factors, such as increased workload, loss of staff, fiscal constraints,

introduction of new technology, etc. Results of an alternatives analysis, i.e. relative merits of alternative approaches The cost of taking no action

2.3.2 Define Business Objectives and Benefits

Business objectives define the results to be achieved for a project to effectively respond to the need / opportunity. They serve as “success factors” which measure how well the project addresses the business need or opportunity. Objectives can identify ways to improve business processes, enhance UNT’s reputation / name recognition, etc.

Having established the business objectives, now determine the specific benefits. For example, determine whether the project will reduce or avoid costs, improve timeliness or service quality, etc. If possible, quantify operational improvements by translating them into reduced costs.

4/11/2023


2.3.3 Define Project Objectives

Project Objectives are the specific goals of the project. Project objectives lead directly to accomplishment of the business objectives and relate specifically to the immediate goals of the project.

For example, the project objective “implement a new time tracking system” has no value in and of itself. That goal only brings value when it leads to accomplishment of the business objective (e.g. “Reduce costs and improve productivity through improved resource management”).

Project objectives can be described in two ways:

Firm Objectives

Relates to time, cost, and operational objectives Was the project on time? Was the project within budget? Was the full Scope delivered?

Soft Objectives

Relates to how the objectives are achieved Includes attitude, behavior, expectations, and communications Is the Customer happy? Is the Project Team proud of its work? Is Management proud of the Project Team?

Focus on the full set of project objectives, firm and soft, can lead to a more complete project success. Focus only on firm objectives can lead to a situation where the project is delivered on time and within budget, but the customer never uses the product.

4/11/2023


2.3.4 Identify Project Manager

Every aspect of a project requires someone to guide it. Business Justification/Initiation, and specifically development of a Project Charter, is no exception. The Project Manager is responsible for defining the project purpose, gathering strategic and background information and developing budgets / schedules for the life of the project.

The Project Manager may be a Resource Manager (has staff reporting to them) or may be an individual contributor. The Project Manager will coordinate resources and activities across CITC to develop the Project Charter and any other materials required for final project approval.

In addition, the Project Manager’s responsibilities are:

Provide day-to-day decision-making on critical project issues as they pertain to project scope, schedule, budget, methodology and resources

Provide direction, leadership and support to Project Team members in a professional manner at project, functional and task levels

Ensure project documentation is complete and communicated Identify funding sources and facilitate the prioritization of project requirements Manage the planning and control of project activities and resources Develop and manage project contracts with vendors Report project status and issues to the project Sponsor and the Steering Committee Provide teams with advice and input on tasks throughout the project, including

documentation, creation of plans, schedules and reports Resolve conflicts within the project between resources, schedules, etc. Influence Stakeholders and team members in order to get buy-in on decisions that

will lead to success Delegate responsibility to team members

4/11/2023


2.3.5 Identify Sponsor

The Sponsor is the individual, generally a CITC Director, who is responsible for the strategic direction and financial support of a project. Although not mandatory, the Project Manager is usually the Sponsor’s direct report within CITC. A Sponsor should have the authority to secure resources and resolve organizational and priority conflicts.

It has been shown in project management circles that lack of correct project sponsorship can be a major contributor to project failure. Conversely, an appropriately placed and fully engaged Sponsor can bring a difficult project to successful conclusion.

The Sponsor’s responsibilities are:

Champion the project and the Project Team Empower the Project Manager Sell the project business case and ensure sustained buy-in Ensure timely availability of resources Clear roadblocks Determine final funding and direction Approve plans, schedules, and budgets Review project progress Serve as executive liaison to upper management

Depending on the scope and visibility of the project, an Executive Sponsor may also be identified. The Executive Sponsor provides support for the Project Sponsor and the Project Manager and is the ultimate decision-maker regarding strategic direction, funding, scope, and approvals to proceed to each succeeding Project Phase.

For CITC-funded projects, the Executive Sponsor would be the Associate Vice President for Computing and Chief Technology Officer. For projects funded outside of CITC, the Executive Sponsor could be a business unit head who is championing the initiative.

2.3.6 Ensure Alignment with Strategic Direction

It is important that we engage in projects that effectively support the UNT business strategy. To ensure this, the alignment needs to be visible and understood by everyone involved.

Using the business strategy and strategic objectives as a baseline during project initiation will save time and effort later. This works best when CITC’s business partners are an integral part of the process.

Review the alignment of the proposed project with supporting documents such as:

UNT Five Year Strategic Plan UNT / State of Texas mandates CITC Strategic Directions Current business and technical environment

4/11/2023


2.3.7 Define Project Scope

Provide a concise statement of what the project will accomplish (in scope), and, where appropriate, what it will not try to accomplish (out of scope). There are two kinds of Scope: Product Scope and Project Scope.

Product Scope is a detailed description of the product or service that would be produced as an outcome of the project

Project Scope is a statement of the work required to create and implement the product or service as well as the work

The Project Scope section of a Project Charter is generally written at a fairly high level and provides a basis for the detailed (product) scope statement in the Planning Review Gate of the CITC Project Management Framework.

2.3.8 Develop Preliminary Budget and Milestones

The Business Justification/Initiation Review Gate of most projects is a time of uncertainty. While there may be general agreement on the scope of the project, specifics of implementation may not be available. For this reason, it may not be possible to provide anything more than a preliminary budget and a high level milestones, and even then only with fairly large confidence limits (e.g. +/- 20% or more).

First, estimate the one-time development / acquisition / implementation costs (including contractors, hardware, software, etc.). CITC internal labor is considered a “sunk cost” and should not be included in the total cost estimate.

Next, produce a milestone schedule for at least the high-level tasks of the project. Project Phase milestones (e.g., Business Justification/Initiation, Planning, etc.) should be included at a minimum.

Milestones could include the typical steps of the System Development Life Cycle (e.g. gather requirements, create specifications, develop a test plan), and tasks specific to the project at hand (e.g. procurement, conversion, training for end-users, training for technical staff, post-implementation support, etc.).

When planning for staged project implementation (e.g., implement a new general ledger first, then purchase and roll out accounts payable and payroll modules in subsequent stages), use only as many stages that provide improved management control over the program as a whole. There should be identifiable deliverables for each stage.

Many late or over-budget projects deemed “failures” are actually only estimating failures. This can happen when estimates based on inadequate data (usually the case during Business Justification/Initiation) are published as “final”. One useful strategy is to re-estimate at the start of each Project Phase as more information is available.

4/11/2023


2.3.9 Identify Project Constraints and Assumptions

All projects have constraints, and these need to be defined from the outset. Projects have resource limits in terms of people, money, time, and equipment. While these may be adjusted up or down, they are considered fixed resources by the Project Manager.

Similarly, certain criteria relevant to a project are assumed to be essential. For instance, it is assumed that necessary budget appropriations will be made to fund a project.

Project assumptions need to be defined before any project activities take place so that time is not wasted on conceptualizing and initiating a project that has no basis for funding, or inadequate personnel to carry it out.

2.3.10 Develop Project Organization (Governance)

Project organization is used to define overall roles and responsibilities and coordinate the activity of the project. Project organization is needed for every project, and the Project Manager and Sponsor must always be identified. The Steering Committee or other governing body should be identified when applicable. This could be in the form of a simple Visio diagram depicting the project reporting hierarchy (e.g., Team reporting to Project Manager; Project Manager reporting to Sponsor, etc.).

There is a distinction between a project reporting hierarchy and an organizational hierarchy. Organizational hierarchies are established primarily to manage people and are perpetual in nature. Project reporting hierarchies are established to manage processes that cross organizational boundaries and are short-lived.

Teams report functionally to the Project Manager during the time they have been made available to the project by their Resource Manager (Administrative Supervisor). Once the project is closed, the project reporting hierarchy is dissolved.

The larger the project, the more critical the organizational structure becomes. In a small project, a single team member may be responsible for several functions, whereas in a large project, each function might require full-time attention.

Confusion and lack of productivity are the result of poor project organization. A good organization facilitates communication and clearly defines roles and responsibilities.

4/11/2023


2.3.11 Identify and Engage Key Stakeholders

Stakeholders are all individuals, internal and external to CITC, who have a vested interest in the success or failure of the project. Key Stakeholders are a subset of Stakeholders, who, if were removed, may cause the project to fail. During Business Justification/Initiation, Key Stakeholders help define, clarify, drive, change, and contribute to the definition of scope and, ultimately, to the success of the project. To ensure project success, Key Stakeholders need to be defined early in the project. It is essential to determine their needs and expectations, and to manage and influence those expectations over the course of the project. Key Stakeholders who are not sympathetic to the goals of the project must be influenced in such a way that they either become supporters or bring themselves into a place of neutrality.

If the project will have an impact on the business processes, work habits or culture of an organization, steps should be taken during Initiation to prepare for the process of Organizational Change Management.

2.3.12 Perform Initial Risk Evaluation

A risk is any unplanned factor that may potentially interfere with successful completion of the project. A risk is not an issue - an issue is something you face now.

A risk is the recognition that a problem might occur (e.g., unavailability of a particular resource due to their on-going production support demands). By recognizing potential problems, the Project Team can plan in advance on how to deal with these factors.

During the Business Justification/Initiation Review Gate, a Risk Evaluation is performed via a simple questionnaire in order to identify the overall risk parameter associated with the project (i.e., Low, Medium, or High). A more detailed Risk Assessment will be performed during the Planning Review Gate.

4/11/2023


2.4 Deliverables


2.4.1 Project Plan

The project plan includes details of activities 2.3.1 through 2.3.9.

2.4.2 Project Charter

The Project Charter encompasses the Project Plan plus the remainder of the activities in the Business Justification/Initiation stage. It defines the scope, objectives, and overall approach for the work to be completed from the perspective of the delivering organization. It is a critical element for initiating, planning, executing, and assessing the project. It should be the single point of reference for project goals and objectives, scope, organization, estimates, work plan, and budget.

Project Charters can appear in many forms depending on the size, complexity, importance and level of risk of the project. We generally will need to know more about large projects that represent a substantial investment (see Appendix B).

2.4.3 Sign-Offs

Two approval procedures are required before a project can proceed to the Planning Review Gate: the approval of the Project Plan and the approval of the Project Charter. The first approval insures that a project is important enough and cost-effective enough to proceed with developing a full Project Charter. The approval of the Project Charter is done to insure that a business and management plan is in place to effectively bring the project to a successful conclusion. If final authorization is obtained to proceed (i.e., deliverables sign-off), the Business Justification/Initiation Review Gate is ended and the Planning Review Gate begins. The position/group with authority to approve the project at this stage (and other stages) is documented in Appendix A.

4/11/2023


3 PLANNING REVIEW GATE

3.1 Overview

Project planning follows the Business Justification/Initiation Review Gate and is considered to be the most important stage in project management. Project planning is not a single activity or task. It is a process that takes time and attention. Project planning defines the project activities and describes how the activities will be accomplished. Time spent up-front identifying the proper needs and structure for organizing and managing projects saves countless hours of confusion and rework in the Implementation Review Gate of the project.

The purpose of the Planning Review Gate is to:

More clearly define the product scope Establish more precise cost and schedule estimates for the project Obtain management approval Provide a framework for review and control

Without planning, a project’s success will be difficult, if not impossible. Team members will have limited understanding of expectations, activities may not be properly defined, and resource requirements may not be completely understood. Even if the project is finished, the conditions for success may not have been defined.

Project planning identifies several specialized areas of concentration for determining the needs for a project. Planning will involve identifying and documenting product scope, tasks, schedules, risk, and staffing needs. The identification process should continue until as many of the areas as possible of the chartered project have been addressed.

Inadequate and incomplete project planning is the downfall of many high-profile, important projects. An adequate planning process and Project Plan will ensure that resources and team members will be identified so that the project will be successful.

The planning process includes (but is not limited to) the following steps:

Estimate the size of the project Estimate the resources required Identify and assess risks Produce a schedule Negotiate commitments

Completion of these steps and others is necessary to develop the Project Plan. Typically, several iterations of the planning process are performed before a plan is actually completed.

4/11/2023



Identification of Project Manager with a track record of success Ensure that key resources are available as required by the Project Plan

4/11/2023


3.3 Activities

The following is a list of key activities required to plan a project:

3.3.1 Develop Product Scope Statement

The development of a product scope statement provides the basis for future project decisions. This statement is of singular importance to the project because it sets the final guidelines as to the breadth and depth of the product(s) delivered, customer acceptance criteria, and procedures to be followed.

The content of this statement will include the following:

Specific product deliverables and their characteristics (high level specs) Customer acceptance criteria What type of processes will be used to manage the project

3.3.2 Develop Procurement Plan

Document a procurement plan that identifies those needs of the project that need to be met by purchasing products or services from outside vendors. This should be done in cooperation with CITC Administrative Officers, Purchasing and Payment Services (PPS), and Legal where applicable. Refer to specific CITC procurement guidelines and policies as they relate to the Procurement Plan.

NOTE: major information technology projects, defined in TAC 216, require a separate stage and more extensive documentation than other types of projects at UNT.

The procurement plan deals with matters such as:

Implementation Services (i.e., contract labor) Software Evaluations & Purchases Hardware Purchases & Maintenance Contract Types (e.g., Fixed Price; Not-To-Exceed; Time and Materials) RFPs (in cooperation with PPS)

4/11/2023


3.3.3 Develop Resource Plan

Every department has a limited number of resources to perform tasks. A Project Manager’s primary role is to find a way to successfully execute a project within these resource constraints. Resource planning is comprised of establishing a team possessing the skills required to perform the work (labor resources), as well as scheduling the tools and equipment (non-labor resources) that enable completion of the project.

Identify Required Skills by Role

It is helpful in the planning process to develop a list of skills required, first for execution of the project and then for execution of each task. This skills list may then be used to determine the type of personnel required for the task.

Assign / Acquire Project Team

A project needs to establish its own pool of available resources (in cooperation with CITC Resource Managers). The resource pool typically specifies the type, level (e.g., skill and experience), and time period that the resource is available.

The Project Manager pragmatically assesses the skills of the available people on the project. The Project Manager’s job is to determine the risks associated with the available skills and to build a plan that realistically accounts for those skills.

Unfortunately, skill level is not a yes / no factor. People have varying degrees of skill, and the Project Manager needs to determine the level of schedule adjustment that should be made based on the project staff skill level.

Where staff with the necessary skills is largely unavailable for assignment on the project, an option (given funding) may be to go outside for the necessary talent or contract services to perform the work. Arrangements should be made to backfill assigned Team Members’ roles if necessary.

Identify Other Resource Requirements

All Project Teams require the tools to successfully perform the tasks assigned. In scheduling resources, the Project Manager must ensure that both people and the equipment necessary to support those people are available simultaneously.

The need for adequate workspace is often overlooked when planning a project. Ideally, the team should be placed in contiguous space (co-located) to facilitate interaction and communication. Team spirit and synergy is enhanced and chances for project success are increased when everyone is close together.

Ensuring the availability of equipment at critical points in the project is crucial to planning a successful project. It is also important to give each team member the right tools they need to do the job. For example, information exchange and communications tools should be provided for Project Team members and project Stakeholders.

4/11/2023


3.3.4 Create Schedule

Develop a Work Breakdown Structure (WBS)

The WBS provides the capability to break the scope into manageable activities, assign responsibility to deliver the project scope, and establish methods to structure the project scope into a form that improves visibility for management. The WBS is based on a well-documented project scope. A WBS is a hierarchical representation of the products and services to be delivered on a project. Elements of scope are decomposed to a level that provides a clear understanding of what is to be delivered for purposes of planning, controlling and managing project scope. In its entirety, a WBS represents the total scope of a project.

A WBS is neither a schedule nor an organizational representation of the project; instead, it is a definition of what is to be delivered. Once the scope is clearly understood, the Project Manager determines how it will be delivered and who will deliver it.

Identify Tasks and Sequences

One of the most important parts of the Project Planning process is the definition of tasks that will be undertaken as part of the project. Tasks are developed by first determining via the WBS what products need to be delivered to accomplish the project objective. The Project Manager is responsible for defining all top-level tasks driven by the WBS and then further decomposing them as planning continues.

This is subjective and reflects the preferences and judgment of the Project Manager. As levels of the WBS become lower, the scope, complexity and cost becomes smaller and more accurate. The lowest-level tasks, or work packages, are the independent, manageable units that are planned, budgeted, scheduled (e.g., timeline) and controlled individually.

Sequencing involves specifying the order of completion of tasks. Much of this has already been done within the process of creating the WBS. Top and mid-level WBS tasks are candidates for summary level tasks with the timeline.

Estimate Duration / Effort

There is no simple formula to define how detailed a task needs to be. There are, however, some helpful guidelines for completion:

Break down the work until the estimates of cost and resources needed to perform the task can be provided (i.e., easier to estimate, easier to assign, easier to track)

If the time period to complete a task is too long, an accurate project status in the Implementation Review Gate may not be possible

If the time period is too short, the task may actually be an activity (the “how” vs. the “what”) which is in essence “micro-managing”

An industry-standard rule of thumb is that a task should not be smaller than 8 labor hours or larger than 80 labor hours (typically translates into work packages between 1 and 10 days duration)

4/11/2023


Determine Task Dependencies

A schedule denotes a hierarchy of task relationships (e.g., Task “B” starts after Task “A” finishes). Task completion eventually rolls up into summary task completion, which ultimately results in project completion. Some task dependencies follow the natural sequence of tasks within the hierarchy whereas some tasks run in parallel (e.g., Task “C” and “D” both start after Task “B” finishes).

There can also be relationships between tasks that are not within the outlined hierarchy (e.g., from other projects). These relationships need to be documented as well. If the tasks are not organized efficiently, it becomes difficult to schedule and allocate resources.

Develop Project Schedule

Following the definition of project tasks, they are associated with time and resources to create a project schedule. The project schedule provides a graphical representation of predicted tasks, milestones, dependencies, resources, task duration and deadlines. The project schedule should be detailed enough to show each work breakdown structure task to be performed, name of the person responsible for completing the task, start and end date of each task, and expected duration of the task. Be sure to verify that people assigned to the Project Team are all assigned a task.

Establish Project Checkpoints

To ensure that the project progresses satisfactorily, management checkpoints or milestones should be clearly defined with planned dates to measure progress. Checkpoints are high-level milestones. Key Stakeholders use them to approve the completion of a phase or milestone and as go / no-go decision points to proceed with the project. The checkpoints ensure that the products and services delivered meet the project objectives.

3.3.5 Refine Project Budget

Budget planning is done in parallel with project schedule development. Budgeting, performed at the initial stages of Project Planning, is the determination of costs associated with the defined activities.

Initial budgetary estimates are often based on availability of funds and may not coincide with the actual funds needed to perform the project. For this reason, budget estimates are refined in the Planning Review Gate until they are “base-lined” at the beginning of the Implementation Review Gate.

Budgeting serves as a control mechanism where actual costs can be compared with and measured against the budget. When a schedule begins to slip, cost is proportionally affected. When project costs begin to escalate, the Project Manager should revisit the Project Plan to determine whether scope, budget or schedule needs adjusting.

To develop the budget, the applicable cost factors associated with project tasks are identified (e.g., contract labor, software, hardware, travel). As mentioned previously, CITC internal labor is considered a “sunk cost” and should not be included in the overall figure.

4/11/2023


3.3.6 Perform Risk Assessment

During the Business Justification/Initiation Review Gate, a simple Risk Evaluation was performed in order to identify the overall risk parameter associated with the project (e.g., Low, Medium, or High). As more information is gathered during the Planning Review Gate, specific project risks may begin to become apparent. It is advisable, especially for projects with an overall risk parameter of “Medium” or above, to perform a more detailed risk assessment in order to document potential risks and establish mitigation plans.

A risk is not an issue - an issue is a situation that has already occurred. A risk is the recognition that a problem might occur. By recognizing potential problems, the Project Manager can attempt to avoid or minimize a problem through proper actions. Good risk management can be leveraged to prevent many risks from turning into real issues.

Risk Management is of much greater concern to the technology Project Manager than to the non-technology Project Manager. For example, Technology Project Managers may be responsible for projects that are working with undeveloped or unproven technologies.

3.3.7 Develop Organizational Change Mgt Plan

Some of the details related to organizational change management will not become apparent until the completion of the solution’s detailed design. Nevertheless, the expectation during the Planning Review Gate is to develop a high-level understanding of the impact of the project on the organization.

Organizational Change Management Process:

Identify potential organizational changes and impact Refine business process improvement opportunities Identify training needs (e.g., magnitude) Determine knowledge transfer resources and processes Document all of this in the Organizational Change Management Plan

3.3.8 Develop Quality Management Plan

The quality management process is the application of quality methods and tools to focus on business and project requirements and to manage work processes with the objective of achieving continuous improvements.

During “Quality Planning” the Project Team:

Identifies those quality standards relevant to the project (e.g., programming) Determines how best to meet those standards. The activities within the quality

planning process basically translate existing quality policy and standards into a Quality Management Plan through a variety of tools and techniques.

“Quality Assurance” requires that the Project Team evaluate overall project performance on a regular basis to provide confidence that the project will meet the relevant quality standards. This involves the use of quality audits to ensure that quality standards and the business and project requirements are met.

4/11/2023


The Project Team conducts “Quality Control” by:

Monitoring specified project results to determine standards have been met Discovering and implementing ways to eliminate unsatisfactory performance.

Successful quality processes always strive to see quality through the eyes of the end user (customer). Customers are the ultimate judges of the quality of the product they receive. They will typically judge a project by whether or not their requirements are met. To ensure delivery of a quality product, the Project Team should ensure that requirements are addressed at each phase of the project.

It is important to include a process that validates the currently defined requirements will be satisfactory to the customer. It is counterproductive to develop a system that meets a documented requirement if you and the customer know that the requirement has changed. The Scope Change Management process helps to control the number of such changes, but quality processes must be in place in order to make changes when they are necessary:

Define quality standards Define quality management processes Document these in the Quality Management Plan

3.3.9 Develop Communication Plan

Communications planning involves defining the information needs of project Stakeholders and team members, as well as identifying which people need what information, when it will be needed (e.g., weekly, monthly, quarterly), and how they will get it (e.g., memo, e-mail, web).

Communication is the cornerstone of how work gets done among different parties within a project. Communications planning is a process that overlays all other parts of Project Planning as well as the other project management phases. It addresses the way in which we transfer / share information about what needs to be done, how it will be done, when it needs to be done, who will do it, status reporting, issues management, problem resolution, etc.

This information is documented in the Communication Plan.

4/11/2023


3.4 Deliverables


3.4.1 Project Plan

The Project Plan is a formal, approved set of artifacts (compilation of text and stand-alone deliverables) used to manage and control project execution. The creation of the Project Plan commences with the Business Justification/Initiation Review Gate and is concluded at the end of the Planning Review Gate. The level of detail should be appropriate for the scope, complexity and risk of the project.

The development of the Project Plan is an iterative process. Each element of the plan is regularly revisited for changes and refinements based on further analysis and decisions made in developing other plan elements. This refinement develops buy-in from the project Stakeholders.

The following is a list of key components of the Project Plan:

Project Charter (from Business Justification/Initiation Review Gate) (Product) Scope Statement Procurement Plan Resource Plan Detailed Schedule Refined Budget Risk Assessment Organizational Change Mgt Plan Quality Management Plan Communication Plan

3.4.2 Sign-Off

Once the Project Manager completes the Project Plan, it should be reviewed and approved by the appropriate person/group (defined in Appendix A.) The level and extent to which the plan will be reviewed is based on the size or visibility of the project. Ultimately, the review process allows for management buy-in and approval. Once the Project Plan is approved and signed, the Project Manager is given the authority to complete the current project efforts and enter into the Implementation Review Gate.

4/11/2023


4 SOLICITATION AND CONTRACTING REVIEW GATE (MAJOR PROJECTS ONLY)

4.1 Overview

For major information technology projects, defined in TAC 216, a separate review gate and more extensive documentation is required for procuring goods and services.

4.2 Activities

See DIR Project Delivery Framework:

http://www.dir.state.tx.us/pubs/framework/gate3/index.htm

4.2.1 Deliverables



4.2.2 Sign-Off



4/11/2023





5 IMPLEMENTATION REVIEW GATE

5.1 Overview

A Project Manager’s responsibilities do not stop once the planning of the project is done. Because a Project Manager is responsible to internal and external Stakeholders, the Project Team, vendors, executive management and others, the visibility of the position is intensified because many of these people will now expect to see and discuss the resulting deliverables that were detailed in the Planning Review Gate.

As a Project Manager, it is important to keep oneself from getting “down in the weeds,” especially on large projects. This will allow you to focus attention on enabling the Project Plans and processes and managing the expectations of customers and Stakeholders.

Once a project moves into the Implementation Review Gate, the Project Team and the necessary resources to carry out the project should be in place and ready to perform project activities. The Project Plan should have been completed and “base-lined” by this time as well. The Project Team, and specifically the Project Manager’s focus, now shifts from planning the project efforts to participating in, observing and analyzing the work being done.

The Implementation Review Gate ensures that planned project activities are carried out in an effective and efficient way while ensuring that measurements against specifications continue to be collected, analyzed and acted upon. Without a defined process, each Project Team would run projects using its own best practices, experience, and methods, while certain control, tracking and corrective action activities would be missed.

It is important to note that project execution and control relies heavily on the plans developed in the Planning Review Gate. There is already enough work to do within the Implementation Review Gate of the project; having to reinvent ways of dealing with risk, change requests, training and resource issues, and other such obstacles to progress is impractical and undesirable at this point.

Particular attention must be paid to keeping interested parties up-to-date with project status, dealing with procurement and contract administration issues, and monitoring project issues and risk.

The Implementation Review Gate also includes project control activities. Project control involves the regular review of metrics and status reports in order to identify variances from the planned project baseline. The variances are determined by comparing the actual performance metrics from the Implementation Review Gate against the baseline metrics assigned during the Planning Review Gate.

If significant variances are observed (i.e., variances that jeopardize the completion of the project objectives), adjustments are made by repeating and adjusting the appropriate Project Planning Review Gate strategies and documents.

A significant variance from the plan does not explicitly require a change, but should be reviewed to see if preventive action is warranted. For example, a missed finish date may require adjustments to the current staffing plan, reliance on overtime, or trade-off between budget and schedule objectives.

4/11/2023



Stakeholder Buy-In and Commitment Stakeholder Participation Management Support Proactive Governance Regular Checkpoints Understood Requirements Project is Specific Project is Attainable Project is Measurable Detailed Project Plan The Right People (Project Team!) Quality Communication Change Management Process Issues Management Process Risk Management Process

4/11/2023


5.3 Activities

The following is a list of key activities required to execute a project:

5.3.1 Execute Procurement Plan

As indicated in the Planning Review Gate of the CITC PM Framework, there will be times within the Implementation Review Gate when it is necessary to purchase products or services needed to deliver the project. In these cases, the project Procurement Plan will be put into action in cooperation with CITC Administrative Officers, Purchasing and Payment Services (PPS), and Legal.

Procurement Plan execution includes, but is not limited to: Developing solicitation documents Conducting proposal evaluation and selection Conducting contract negotiations Submitting Purchase Orders

5.3.2 Manage Schedule

It is important for the Project Team to understand at all times exactly where the project stands with respect to project schedule. The procedures used to determine status and then update schedules to depict current work efforts are crucial to ensuring that accurate schedules are maintained. Without these procedures, invalid data may cause inaccurate schedule performance reporting.

Schedule data collection and validation involves the following:

Ensuring that start and end dates, etc. reflect reality Ensuring integrity exists between tasks, sub-plans, and master schedules Ensuring that schedules accurately depict the work being accomplished

Schedule control is one of the most challenging but important activities within project control. The project schedule can be affected by any number of issues from resources to funding, vendors, and anything in between. The ability of a Project Manager to manage the schedule of a project and deliver it on time is a high-visibility concern for project success.

Attributes of Schedule Control include:

Influencing the factors that create schedule changes Ensuring that changes are beneficial Determining that the schedule has changed Managing the actual changes when and as they occur

Schedule issues come from a variety of sources but there should be a single, focused method for dealing with schedule changes. If a potential schedule problem is discovered, the problem must be investigated and the cause uncovered as soon as possible. Once the problem is discovered, a plan should be created for correcting the problem in the shortest allowable time with the least impact. It is also advisable to bring forward alternatives and associated costs.

4/11/2023


Schedule control is something that typically is managed at the project level by the Project Manager. However, it is very important to make the Stakeholders aware that a schedule change has occurred. Furthermore, the Stakeholders need to be made aware of what is being done to fix the issue and the impact it will have on the project’s performance and deliverables.

It is standard practice to baseline the schedule at the start of the project. This allows all schedule changes to be displayed against the original project schedule. If schedule slippage becomes severe it may be advisable to re-baseline the project.

It is a good idea for Project Managers to hold regular project schedule reviews. Large or complex technology projects may have several schedules being managed at a deliverable or functional level. Having the “owners” of these schedules meeting at regular intervals is of great benefit. The Project Manager is responsible for integrating these project schedules and making them understandable for all of the Stakeholders.

5.3.3 Document Work Results

Results are the outcomes of the activities performed to accomplish the project and should be collected and reported. Information on work results consists of input on:

Which deliverables have been completed and which have not To what extent customer obligations are being met What costs have been incurred or committed

General guidelines for documenting work results:

Utilize a central repository for tracking project deliverables Maintain the inventory of project deliverables Update the inventory with deliverable status and quality comments

4/11/2023


5.3.4 Manage Quality

Quality assurance incorporates a process of evaluating overall project performance on a regular basis to provide confidence that the project will satisfy the relevant quality standards. Accordingly, while it is important that each team member be responsible for the quality execution of tasks, a quality team is typically included in the Project Team and plays an integral role in the execution of quality throughout the project.

This team ensures that the quality plan is executed as planned. As an organization’s quality processes mature, the need for the external quality unit decreases. This quality team reports functionally to the Project Manager, but must also have a reporting chain outside the project to facilitate problem escalation. Problem escalation is the process of moving a problem to a higher management level if sufficient attention is not given by the Project Manager. The independent reporting chain provides a check and balance on the project.

Quality control involves monitoring specific project results throughout the project to determine if they comply with relevant quality standards and identifying ways to eliminate causes of unsatisfactory results. Project results include both product results, such as deliverables, and management results, such as cost and schedule performance. Quality control is often performed by a quality control unit, or a similarly titled organization unit, although this is not a requirement.The Project Team should be aware of the following concepts:

Prevention – keeping errors out of the process Inspection – keeping errors out of the hands of customers

5.3.5 Manage Costs

Projects may fail to control costs, or go over budget, for many reasons. Often it is not a single problem but a series of small problems combined that permit cost control to be sacrificed and prevent the project from being completed within budget.

Attributes of Cost Management include:

Influencing the factors that create budget changes Ensuring that changes are beneficial Determining that the budget has changed Managing the actual changes when and as they occur

Cost control is not simply a reporting process. It includes the searching out of the “why” for both positive and negative variances between the scheduled and actual costs. It must be thoroughly integrated with the other control processes (scope change control, schedule control, and others). For example, cost variances can cause schedule problems or produce an unacceptable level of risk later in the project.

Cost control is a process highly valued by technology project Stakeholders. This is also an area where the unpredictability of technology can wreak havoc on the plans laid out within a project. A Project Manager must be able to monitor the actual budgets against the baselines as laid out in the Project Budget. The length and complexity of a project will have a direct impact on its potential to go over budget.

4/11/2023


Setting budget limits and monitoring variances on budgets must be done early and often. Budget problems tend to compound themselves if left unattended. In many cases the budget is a fixed amount. In those cases, if other actions fail to bring the project’s costs into budget alignment, the scope must be reduced.

General guidelines for Managing Cost:

Monitor cost performance to detect variances from the Project Plan Ensure that all appropriate changes are recorded accurately in the Project Budget Prevent inappropriate or unauthorized changes to the Project Budget Inform Key Stakeholders of authorized changes

5.3.6 Manage Risks

Risk identification, monitoring and resolution are key tools for successfully completing a project. Again, a risk is the recognition that a problem might occur. An issue is a situation that has already occurred.

Part of controlling a project during the Implementation Review Gate is to have an established risk management process. This process may begin as early as the Business Justification/Initiation Review Gate and is kept current until the project Benefits Realization/Closeout Review Gate.

General guidelines for managing risks:

Utilize a central repository for risk information Assign a Risk Manager (either the Project Manager or a Team Member) All Stakeholders submit risks for entry into the Risk Log Present reports in regular status meetings for discussion, follow-up, and resolution Provide ongoing evaluation of new risks

Activities include: Identifying a potential risk (e.g., support activities may impact resource availability) Assessing the probability of the risk occurring Assessing the impact of the risk if it occurs Assigning a risk priority and assigning an “owner” Determining the risk response including mitigation / contingency plans

There are four things that can be done about a risk:

Do something to remove it (i.e., avoid it; e.g., use another resource) Make someone else responsible (i.e., transfer it; e.g., the vendor) Take actions to lessen the impact or chance of occurring (i.e., mitigate it; e.g., get

written sign-off for the resource to be made available) The risk probability or impact may be so small that time is better spent on other

project activities (i.e., accept it)

4/11/2023


There is also a positive side of risk. A risk may be seen as a potentially useful outcome that occurs because of some unplanned event. In this case, the Project Team can attempt to maximize the potential of these positive risk event should they occur.

The Project Manager must ensure that project status meetings make time for the discussion of risks in the Risk Log. Short-life task forces may need to be convened for risks that affect a large number of Stakeholders.

4/11/2023


5.3.7 Manage Issues

An issue is basically anything that might affect the project meeting its goals (e.g., technical, functional, financial). A risk is a potential occurrence whereas an issue is something that has actually occurred.

The purpose of the issues management process is to provide a mechanism for organizing, maintaining and tracking the resolution of issues that cannot be resolved at the individual level. The approach consists of issue control mechanisms and a well-defined process that enables the Project Team to identify, address and prioritize issues.

The Issue Management process should give everyone involved with or affected by the project a way to report issues or problems. A mechanism should be provided for documenting the problem, assessing the impact of the problem, making recommendations and determining the time required for resolving the problem. This process may begin as early as the Business Justification/Initiation Review Gate and is kept current until the project Benefits Realization/Closeout Review Gate.

Typically, when the issue or problem has been resolved and verified, recording the actual date the problem was resolved and the approval authority closes the issue. Some issues may need executive management approval. The appropriate processes should be followed to update contracts and baseline documents.

General guidelines for Managing Issues:

Utilize a central repository for the capture of project issues Assign an Issues Manager (either the Project Manager or a Team Member) All Stakeholders submit issues for entry into the Issue Log Review issues on a regular basis (e.g., Project Status Meetings) Track all issues until they are resolved Update issues with resolution and status Depending on the issue, obtain executive management approval Update the appropriate processes and documents impacted by the issue resolution

Activities include:

Recording the detailed description and impact of the issue Recording the owner of the issue Recording the due date of a resolution Recording the on-going progress / status of the issue Recording the resolution and date resolved

The Project Manager must ensure that project status meetings make time for the discussion of issues in the Issue Log. Short-life task forces may need to be convened for issues that affect a large number of Stakeholders.

4/11/2023


5.3.8 Manage Scope

Scope control is a straightforward concept. The intent of implementing a scope control process is to identify and manage all elements (e.g., people and requirements) inside and outside of the project that increase or decrease the project scope beyond the required or defined need of the original, agreed-upon Product Scope Statement.

Attributes of Scope Control include:

Influencing the factors that create scope changes Ensuring that the changes are beneficial Determining that a scope change has occurred Managing the actual changes when and if they occur

Scope changes will come from the perceived need for a change in a project deliverable that may affect its functionality and in most cases the amount of work needed to perform the project. A scope change is a very crucial occurrence.

A scope change most likely will require a change in project funding, resources and / or time. All scope change requests should be submitted in writing. A committee that consists of Stakeholders from all areas of the project should be willing to convene and discuss the potential change and its anticipated impact on the project and the department.

This group of Stakeholders should be a predefined cross section of people that will have the ability to commit their interests at a strategic management level. Once a decision is made to increase or reduce scope, the change must be authorized by all members of the committee. Any changes that are agreed upon must be documented and signed as a matter of formal scope control.

In addition, the impact of the scope change will be felt throughout the Planning Review Gate processes and documents. Documents such as the WBS and Project Schedule will have to be re-evaluated and updated to include the scope change impacts. Scope changes need to be communicated clearly and effectively to the Project Team by the Project Manager. Team members will want, and need, to understand how the scope change affects their area of responsibility.

Scope control is extremely important within technology projects. It is not uncommon when team members are doing their development testing or implementation work for them to try to get creative or give the customer something other than, or in addition to, the original stated requirements.

Doing any work that is outside or beyond the stated work, as called out in the original requirements, is considered “scope creep” or “expansion of scope”. Expansion of scope is much more subtle within technology projects because adding additional features (e.g., adding an extra icon or function to an application) does not appear to be as significant as adding something to a normal project (e.g., adding an extra mile of road to a highway construction project).

4/11/2023


In both cases, the additional scope of work has an impact on other control mechanisms within the project. The scope creep (unnoticed additions or changes to the project from the agreed-upon requirements or specifications that increase the scope of the project) will most likely not be budgeted or scheduled, which means that any small scope change could have a large cost and schedule effect.

Guidelines for Managing Scope:

Identify potential scope changes via a formal change request / request log Evaluate the impact (i.e., additional project funds, resources, or time will be required) Ensure that the scope change is beneficial Discuss the potential change and anticipated impact with Key Stakeholders If a decision is made to change scope, document and obtain sign-off Update all elements of the Project Plan to reflect the scope change Communicate scope changes clearly to all Stakeholders

Activities include: Identifying and documenting potential changes to scope (e.g., deliverables) Determining the revisions to project artifacts needed due to the change in project

scope (e.g., Budget, Schedule) Obtaining approval for the scope change from Key Stakeholders Revising impacted planning artifacts and communicating changes

5.3.9 Manage Organizational Change

All departments that develop and execute projects have formal and informal policies that may affect Project Plan execution. Project Implementation may also lead to the realization of the need for new polices or alteration of existing policies. Any consideration for new CITC policies and procedures should be documented during the Implementation Review Gate and reviewed for implementation.

General guidelines for managing Organizational Change:

Ensure that the Organizational Change Management Plan is executed as planned Participate and endorse Organizational Change activities Revise the Organizational Change Management Plan based on feedback received

from Stakeholders and Project Team Members

5.3.10 Communicate Information

The project Communication Plan is an important factor in the Implementation Review Gate. A large part of a Project Manager’s responsibility during this stage of the project is keeping the Stakeholders informed of project status. There are many facets to project communications.

Joint project reviews are a good way to bring visibility to all areas of the project. They provide an opportunity to discuss important issues and make management decisions on the project with input from several sources. The frequency and topics covered at these meetings should be outlined in the Communications Plan.

4/11/2023


The Project Manager may be requested to make monthly reports to the Steering Committee or other management group. Meeting minutes should be made available to Stakeholders along with any “to-do” lists that may have been generated during the meetings.

All elements of the Project Plan should be accessible to the Stakeholders via shared storage, a project web site, or other means. The Communication Plan may specify that particular Stakeholders receive portions of the Project Plan in varying format, depending on their communication needs.

The Project Manager should stay in constant communication with the Project Team, both formally and informally, and revise the Communication Plan based on feedback. Informal discussion is sometimes the best way to determine team morale, true project status, looming challenges, etc.

5.3.11 Conduct Status Review Meetings

While the Project Manager is responsible for relaying project status to parties outside the Project Team, the Project Team is, in turn, expected to report status to the Project Manager. This includes communicating information on both a formal and informal basis. Formal mechanisms such as status reports, status meetings, and action item reviews can be very specific. Informal processes, such as hallway conversations, can be very helpful as well.

Status reporting is an integral part of the project management process. It is the means by which the Project Team and executive management stay informed about the progress and key activities required to successfully complete the project. The purpose of the status report is to provide a standard format for the formal exchange of information on the progress of the project.

The information shared in the status report should be in a consistent format throughout the project. Status reports typically detail activities, accomplishments, milestones, identified issues and problems. Mitigation strategies should be prepared for anticipated problems.

Status meetings are conducted to discuss project status and to set direction and priorities for the project. The level of detail and objective of status reports and status meetings vary based upon the audience, project size and impact, and the risk associated with a project.

The three primary status audiences are:

Project Team

For the Project Team, status reports and meetings cover the lowest level of detail. This is a forum for the Project Manager to discuss project progress and status with the team and to implement project direction and priorities as set by the Sponsor (and possibly the Steering Committee). Larger projects, which are divided into teams, will also conduct team status meetings. Project Status Meetings are typically conducted every week.

4/11/2023


Sponsor / Executive Sponsor

The Sponsor / Executive Sponsor Status Meeting is a venue for the Project Manager to discuss key project issues. The Sponsor(s) will assist the Project Manager in resolving key issues and help set project direction and priorities. At a minimum, Sponsor / Executive Sponsor Status Meetings should be conducted once a month. Typically, these meetings will occur more frequently for large complex projects with high risks.

Steering Committee

The steering committee meeting is intended to be a forum for the committee to evaluate the overall progress of the project. In addition, the steering committee sets strategic direction and project priorities. An executive status report, which discusses high-level status, issues and risks, is provided to the steering committee and serves as the basis for the meeting discussion. Steering committee meetings are typically conducted once a month.

5.3.12 Review Project Checkpoints

To ensure that the project is progressing satisfactorily, review management checkpoints or project milestones with Key Stakeholders. These are used to approve the completion of a phase or milestone and as go / no-go decision points to proceed with the project. Depending on the size and complexity of the project, the checkpoint review may be linked to project funding. The checkpoints ensure that the products and services delivered meet the project objectives in the time frame established by Key Stakeholders.

General guidelines for reviewing project checkpoints:

Review associated deliverables of concluded phase Review Risk and Issue Logs Evaluate project progress and ability to meet objectives

5.3.13 Administer Contracts / Vendors

The Project Manager will be responsible for ensuring that the vendors, once contracted to do the work, meet the contractual agreements specified within their contracts. Project Managers will also be responsible for tracking, reviewing and analyzing the performance of contractors on a project. This performance reporting will be the basis for any contractual changes that need to be made during the life of the contract. Finally, Project Managers will play an important role in oversight and review of any contract changes that will affect the project.

Contract administration is the process of ensuring that the vendor’s performance meets contractual requirements. This is accomplished through the use, and monitoring, of a Project Plan from the vendor, periodic progress reports and the completion of deliverables as delineated in a project Statement of Work (SOW).

Project Managers within technology projects tend to manage more contracts than non-technology projects. This is primarily because of the need to bring in contractors who have expertise in particular technology areas. Therefore, monitoring status for the different contractors can become a greater responsibility. The Project Manager is to ensure that the vendors follow appropriate application development and project management methodologies.

4/11/2023


General guidelines for Administering Contracts / Vendors:

Ensure that vendors meet their contractual agreements Track the performance of contractors (e.g., Deliverable Review per SOW) Approve and monitor vendor Project Plan and Status Reports Oversee and review contract changes that will affect the project Ensure vendor compliance with the CITC Project Management Framework Ensure that UNT is fulfilling its contractual obligations

5.3.14 Update Project Planning Documents

During the Implementation Review Gate, the Project Plan is implemented and modified as necessary. Project Plan modifications may result from such things as the following:

New estimates of work still to be done Changes in scope / functionality of end product(s) Resource changes Unforeseen circumstances

Changes to Project Baselines (i.e. Budget, Schedule, and Scope) must be done through use of a formal Change Management Process. The Project Manager may change other Project Plan components (e.g., Communication Plan) as needed.

4/11/2023


5.4 Deliverables


5.4.1 (Formal) Project Status Reports

Weekly / Monthly Status Reports are used to communicate the following key information:

Current activity status (schedule) Significant accomplishments for the current reporting period Planned activities for the next reporting period Financial status Present Issues, Concerns / Risks

Along with the status report form, the following may be attached:

Updated Gantt charts Risk / Issues Log Scope Change Log Recovery plans for activities not on schedule Corrective action plans for expected problems Resolution to assigned action items Others, as appropriate

Executive status reports may be created as well if they will enhance communication with management.

5.4.2 Updated Planning Documents

Deliverables in this Phase include consistent and updated planning documents such as the project schedule, communication plan, etc. There should be a formal review and approval process for updated planning documents.

5.4.3 Project-Specific Deliverables

These deliverables depend on the nature of the project. Most of these deliverables should have been identified during the Planning Review Gate.

Examples of these project-specific deliverables might include functional design documents, test plans, a training plan, a database design document, a program specification, etc.

5.4.4 Sign-Off

If final authorization is obtained to proceed (the authorizing person/group is defined in Appendix A), the Implementation Review Gate is ended and the Benefits Realization/Closeout Review Gate begins.

4/11/2023


6 BENEFITS REALIZATION / CLOSEOUT REVIEW GATE

6.1 Overview

The last major Phase of a project’s life-cycle is Benefits Realization/Closeout. This is performed once the Implementation Review Gate is completed and the resulting product has been placed into “production” status.

Benefits Realization/Closeout includes the following key elements:

Verification of formal acceptance by Stakeholders Documenting project successes and challenges Documenting “Lessons Learned” Celebrating project success Producing a Lessons Learned Report

These activities are particularly important on large projects with extensive records and resources.


Customer acceptance criteria met Business objectives are achieved Anticipated benefits are achieved Project objectives are achieved

4/11/2023


6.3 Activities

The following is a list of key activities required to close-out a project:

6.3.1 Conduct Business Outcomes Review Meeting

The issue of primary importance with Business Outcomes Review is the formal acceptance of the product or project deliverables by the customer for which they were created. The best way to ensure this is to convene a final meeting with all necessary Stakeholders to review the product delivered against the baseline requirements and specifications.

By this time, any deviations from the established baseline will have been documented and approved, but it is still good policy to make the Stakeholders aware of the baseline deviations, justifications, and future action plans. Furthermore, any open action items or program level issues can be officially closed or reassigned.

By drawing all of the Stakeholders together in a single meeting, the Project Manager avoids clearing up open issues on an individual basis. The final deliverable of this meeting is the Business Outcomes Review Document which describes project’s final deliverables in comparison with the authorized project baseline documents.

Approval is verified via the signature of a Business Outcomes Review Document by all of the Stakeholders who signed off on the Project Plan. This document should be customized to the particular project to include pertinent deliverables, key features and important information about final product delivery.

6.3.2 Conduct Lessons Learned Meeting

In conducting the Lessons Learned meeting, the Project Manager provides a forum to discuss the various aspects of the project focusing on project successes, problems, issues, and future process improvement recommendations. Using the information and documentation from the Business Outcomes Review Meeting as a basis for discussion, some typical questions to answer in this meeting include the following:

To what extent did the delivered product meet the requirements? Was the customer satisfied with the end product? Were cost budgets met? Was the schedule met? Were risks identified and mitigated? Did the project management methodology work? What could be done to improve the process?

The Lessons Learned Meeting typically includes the following groups:

Project Team Key Stakeholders Executive Management Maintenance and Operations Staff

4/11/2023


The Lessons Learned Report documents the successes and challenges of the project. It is important to include in this report, new ideas that were successful in the project and make recommendations on how these processes might be adapted for other projects.

Parts of this report may be used to share project successes with other organizations, both inside and outside of CITC. In the same way that problem identification can lead to improvements, successes must be shared so they can be repeated.

Where possible, successes should be translated into procedures that can be followed by future projects. The report may also contain recommendations for future projects of similar size and scope.

Guidelines for conducting Outcome Assessment Meeting:

Document project success and challenges Determine the extent that objectives and benefits were achieved Compile “Lessons Learned” Complete Lessons Learned Report Work with the CITC PMO to revise PM procedures based on “Lessons Learned”

6.3.3 Conduct Contract Closure

Contract closure is the process of terminating contracts that outside organizations or businesses have with UNT. These contracts may be vehicles for providing technical support, consulting, or any number of services supplied during the project that we chose not to perform ourselves.

Contracts can be brought to closure for a variety of reasons, including contract completion, early termination or failure to perform. Contract closure is a typical but important part of project management.

General guidelines for conducting Contract Closure:

Review contract and related documents Validate that the contractor has met all of its contractual requirements Validate that UNT has met all of its contractual requirements Document and resolve any variances Ensure that appropriate vendor responsibilities have been transferred to CITC Work with CITC Administrative Officers, PPS, and Legal as needed

4/11/2023


6.3.4 Conduct Knowledge Transfer

Following preparation of the Lessons Learned Report, knowledge is transferred to appropriate groups and project information is archived. Historical project data is an important source of information to help improve project performance in the future.

The specific information archived for a project will vary. Typically, the following project data are archived:

Project Charter Project Plan Financial Records Correspondence Meeting Notes Status Reports Contracts Technical Documents

Most archiving may be done electronically through the Enterprise Project Management System (EPM). All hard-copy records should be stored following standard UNT record-retention guidelines.

General guidelines for Conducting Knowledge Transfer:

Ensure that project documentation has been updated and is complete Ensure documentation is transferred to appropriate groups Ensure that all end users have been adequately trained Ensure that maintenance organizations have been adequately trained Archive project documentation Ensure compliance with UNT record-retention guidelines

4/11/2023


6.4 Deliverables


6.4.1 Business Outcomes Review Document

The Business Outcomes Review Document summarizes the Business Outcomes Review Meeting. This includes, but is not limited to:

Results of the review of the product delivered against baseline requirements List of variances with justifications and future action plans Action items closed or reassigned Approval of Business Outcomes Review via signatures of the Sponsor(s) and Key

Stakeholders

6.4.2 Lessons Learned Report

The Lessons Learned Report summarizes the Lessons Learned Meeting and documents the successes and challenges of the project. This may include references to: Staffing and skills Project organizational structure Schedule management Cost management Risk management Customer expectations management Project management processes Other Lessons Learned

6.4.3 Sign-Off

Once the Business Outcomes Review document has been signed off (see Appendix A) and the Lessons Learned Report is produced, the Benefits Realization/Closeout Review Gate is ended and the project is completed.

4/11/2023


7 KEY ROLES AND RESPONSIBILITIES

7.1 Overview

It is important to have a defined formal structure for the project and for the project staff. This provides each individual with a clear understanding of the authority given and responsibility necessary for the successful accomplishment of project activities.

4/11/2023


7.2 Sponsor

The project Sponsor is typically a CITC Director who is ultimately responsible for the project’s result. The Sponsor is an important Stakeholder, usually head of a program area. This is the person who makes the business argument for the project to exist and usually controls the overall funding of the project.

Depending upon the size and visibility of the project, an Executive Sponsor may also be identified. For CITC-funded projects, this would be the Associate Vice President for Computing and Chief Technology Officer. For projects funded outside of CITC, the Executive Sponsor could be a business unit head who is championing the initiative.

7.2.1 General Functions

Provides support to the Project Team Empowers the Project Manager Ensures that requirements are met Provides necessary funding and resources Champions the project to provide buy-in from Key Stakeholders Monitors project progress

7.2.2 Business Justification/Initiation Review Gate

Provides strategic plans and guidance Defines Sponsor needs Obtains funding for project when necessary Approves and champions the Project Charter

7.2.3 Planning Review Gate

Participates in planning sessions Assigns personnel through the Project Manager Reviews and approves the Project Plan

7.2.4 Implementation Review Gate

Attends executive requirement reviews Helps resolve requirements problems Helps resolve issues, as appropriate Attends as needed at Project Status Reviews Attends Steering Committee meetings

7.2.5 Benefits Realization/Closeout Review Gate

Attends Business Outcomes Review Meeting Signs-off on project completion Attends Lessons Learned Meeting

4/11/2023


7.3 Project Manager

7.3.1 Overview

The Project Manager has total responsibility for the overall project and its successful completion. To succeed in this responsibility, the Project Manager must work closely with the Sponsor to ensure that adequate resources are applied. The Project Manager also has responsibility for planning, ensuring that the project is successfully completed on time, within budget, and that customer objectives are met. The Project Manager must be assigned early so that the project will be “owned” by the person responsible for its execution.


Implements project policies and procedures Acquires resources required to perform work Manages the Project Team Maintains staff technical proficiency and productivity Provides training to Project Team where required Maintains excellent communication with all Stakeholders Establishes and maintains quality in the project Identifies and procures tools to be used on the project


Defines project success criteria Documents project constraints Documents project assumptions Conducts cost-benefit analyses Develops Project Charter


Develops the Project Plan (e.g., Schedule, Communication Plan, etc.) Ensures that all Stakeholders agree to project commitments Ensures that the Project Plan is approved and “base-lined” Assigns resources to project and assigns work packages


Manages day-to-day tasks and provides direction to the Project Team Reviews project status, comparing budgeted to actual values Reviews project schedule, comparing baseline to actual work completed Ensures that Project Plan updates are made and signed-off on as needed Updates budgets and schedules and makes recommendations as needed Reviews project issues, risks and establishes mitigation procedures

4/11/2023



Develops an action plan for any product deficiencies, open issues, etc. Obtains customer and management approval of completed project Closes-out open action items Conducts Business Outcomes Review Meeting Creates Business Outcomes Review document Conducts Lessons Learned Meeting Creates Lessons Learned Report Assists as needed with any post-project delivery audits Assists PPS contract administrator(s) in contract closeout Archives all project data Celebrates success with Stakeholders and the Project Team

4/11/2023


7.4 Steering Committee

7.4.1 Overview

The Steering Committee is responsible for providing guidance on overall strategic direction. It does not take the place of a Sponsor, but helps to spread the strategic input and buy-in to a larger portion of the organization. Depending on the size and visibility of the project, it may consist of Stakeholders at various levels of organizational authority across multiple departments, including the Customer department.


Establishes business goals and objectives for the project Ensures that sufficient resources are available to participate in projects Reviews / approves commitments to external entities (e.g., vendors) Participates in key project decisions (both strategic and tactical)


Reviews / approves Project Charter


Reviews / approves the Project Plan


Reviews projects at regular Steering Committee meetings Approves changes to the Project Plan baselines Reviews risk-mitigation plans and acts on Project Manager’s recommendations Reviews / approves changes in contract commitments Reviews / approves project deliverables Approves project / phase completion


Attends Business Outcomes Review Meeting Signs-off on Business Outcomes Review Document, if key Stakeholder Attends Lessons Learned Meeting

4/11/2023


7.5 Project Team

7.5.1 Overview

The Project Team has responsibility for conducting project activities. Project Team members, as necessary, assist the Project Manager in planning the development effort and help construct commitments to complete the project within established schedule and budget constraints. The Project Team may include the subject matter experts responsible for implementing the project solution. Customers and / or Stakeholders should interact with the Project Team to ensure that requirements are properly understood and implemented.


Identifies technical solution alternatives Implements solution within budgeted cost and schedule Supports Project Planning and tracking


Provides estimates for developing products Ensures that requirements are feasible and appropriate for available resources Analyzes requirements for completeness, consistency, and clarity


Develops technical approach Assists in development of estimates and schedules Identifies tools needed for the project Ensures that all members of the Project Team understand the Project Plan Identifies staff training needs Ensures that project execution staff fully understands requirements


Creates product and process solutions Tracks the project execution effort and submit status reports Conducts internal and external reviews and walkthroughs Creates testing plan and coordinates test activities Executes assigned project tasks Identifies problems and schedule fixes Identifies and reacts to risks as they are found Participates in change reviews


Participates in Business Outcomes Review Meeting, as appropriate Participates in Lessons Learned Meeting, as appropriate Identifies ways to improve project processes Turns over all project-related documentation to the Project Manager for archiving

4/11/2023


8 APPENDIX A – PROJECT APPROVAL STRUCTURE

Final Approval Authority by Project Size*Project Stage Governance

StepMinor Small Medium Large

Business Justification/

Initiation

Project Plan Approval

Business Unit

Business Unit

Business Unit

Business Unit

Charter Approval

Business Unit

Business Unit

ITSC ITSC

Planning Project Plan Approval

Business Unit

Business Unit

ITCPG ITCPG

Implementation

Implementation-Specific Planning

Document Approval

Business Unit

Business Unit

ITCPG ITCPG

Project Progress Review(s)

Business Unit

Business Unit

ITCPG ITSC

Benefits Realization/

Closeout

Business Outcomes

Review Approval

Business Unit

Business Unit

ITCPG ITSC

*Approval Authority by Project Size: the following persons or groups have final approval authority for the project classified:

Business Unit: the manager of the end-user or in some cases, the CITC department that initiated the project request. CITC departments typically would initiate projects that are technical and/or maintenance in scope, while end-user departments would initiate projects that the CITC would perform on behalf of those departments (such as writing a new EIS report.) The business or CITC manager who signs off on the approval generally would have budgetary authority to expend funds and/or assign personnel to work on the project.

ITCPG: an Information Technology Council Planning Group. The Planning Group whose scope of interest most closely aligns with the project being proposed approves the project. The Planning Groups are:

o Instructiono EIS Program Managemento Communicationso Standards & Policyo Student Computing

ITSC: – the Information Technology Steering Committee. The ITSC, as defined by Policy xx.x: Information Technology Advisory Committees at UNT

4/11/2023


9 APPENDIX B – PROJECT CLASSIFICATIONS

The table below prescribes various levels of Project Management rigor depending on effort, complexity, etc. (projects are distinguished from operational activities). For example, “Large” projects require the full framework (including a Project Charter) whereas a “Small” project primarily requires a detailed schedule / timeline driven by a Work Breakdown Structure (WBS). Finally, a “Minor” project requires only basic attribution definition and business justification as a Project object within the Project Portfolio System (e.g., description, business need, start date, finish date.)

Line # Review Gate Item Component Description Minor Small Medium Large

1 Business Justification

Project Request Project Name Short name for the project (same as used in EPM system)

Yes Yes Yes Yes


Project Request Customer Dept Customer department requesting project Yes Yes Yes Yes


Project Request Customer Priority? Low, Medium, High Yes Yes Yes Yes


Project Request Project Description Concise description of the project which will result in the desired product(s)

Yes Yes Yes Yes


Project Request Business Need Concise descriptions of the immediate business need (justification). PLEASE NOTE THIS IS NOT THE SAME AS THE VERY SPECIFIC BUSINESS OBJECTIVES WHICH ARE PART OF THE REQUIREMENT FOR PROJECTS SENT THRU THE FRAMEWORK. ALL SIZES OF PROJECTS WILL REQUIRE MINIMAL JUSTIFICATION VIA THIS FIELD

Yes Yes Yes


Project Request Alternatives Business alternatives to invoking project Yes Yes Yes


Project Request Product Owner (Requestor)

Customer representative who takes delivery of the product produced by the project (e.g., Walter Bowen for CRM)

Yes Yes Yes Yes


Project Request Funding Identification

Identified, Not Identified, Not Needed Yes Yes Yes


Project Request UNTS Affiliate(s) Impacted

UNT,HSC,DAL,SYS,UCD Yes Yes Yes Yes

4/11/2023




Project Request Proposed Start Customer proposed start date Yes Yes Yes Yes


Project Request Proposed Finish Customer proposed finish date Yes Yes Yes Yes


Project Request Mandate Type Internal (UNTS) / External (State) Yes Yes Yes


Project Request Mandated By Internal or external organization issuing mandate (e.g., DIR)

Yes Yes Yes


Project Request Deadline Hard deadline if exists (internally or externally mandated)

Yes Yes Yes


Project Request Impact if not implemented

e.g., Non-compliance w/DIR PM initiative Yes Yes Yes


Assessment Magnitude <= 1 wk,<= 1 mo,<= 3 mo,<= 6 mo,<= 12 mo,> 12 mo

Yes Yes Yes


Assessment Rank Rank within the project portfolio (1-n) Yes Yes Yes


Assessment Capital Forecast (Capital Cost)

Initially forecasted capital expense Yes Yes Yes Yes


Assessment Labor Hrs Forecast (Labor Hours)

Initially forecasted total labor hours to complete project

Yes Yes Yes Yes


Assessment Project Category New Initiative, Enhancement Yes Yes Yes


Assessment Service Area The particular service area within CITC that is tied to the project (or operational activity)

Yes Yes


Assessment Project Classification

Minor, Small, Medium, Large Yes Yes Yes Yes

4/11/2023




Assessment Risk Low, Medium, High Yes Yes


Assessment Product/Application Product or application system tied to the project Yes Yes


Portfolio Approval

Portfolio Approval Status

Proposed, Approved, Rejected Yes Yes Yes Yes


Portfolio Approval

Disapproved Reason

Business reason the project was not approved for inclusion in the project portfolio

Yes Yes Yes Yes

27 Intentionally left blank

28 Initiation Full Business Case/Project Charter

Schedule Flexibility Low, Medium, High Yes Yes Yes


Scope Flexibility Low, Medium, High Yes Yes Yes


Resource Flexibility Low, Medium, High Yes Yes Yes


Project Manager The individual within CITC who is responsible for the day-to-day management and delivery of the project (e.g., Andy Novak for EPM)

Yes Yes Yes Yes


Project Sponsor The CITC Senior Manager (usually a Director) responsible for strategic direction and financial support of the project (e.g., Charlotte Russell for EPM)

Yes Yes Yes Yes


Exec Sponsor Top-level executive who provides support for the Project Sponsor and the Project Manager and is the ultimate decision-maker regarding strategic direction, funding, scope, and approvals to proceed (e.g., Maurice Leatherbury for EPM). For CITC-funded projects, the Executive Sponsor would be the Associate Vice President for Computing and Chief Technology Officer. For projects funded outside of CITC, the Executive Sponsor could be a

Yes Yes

4/11/2023



business unit head who is championing the initiative


Oversight Authority

External oversight body having management control over the project (e.g., CITC Mgt for EPM)

Yes Yes


Performer Group responsible for project delivery Yes Yes Yes Yes

36 Initiation Full Business Case/Project Charter EPM

Work Type Project, Operations Yes Yes Yes Yes


Operations Type Support, Minor Enhancement Yes Yes Yes Yes


DIR Flag Project meets DIR Major project criteria Yes


Business Unit Purchasing Project Number (if applicable)

Cross-reference that associates an EPM Project with one (or more?) Project Numbers that exist in the CITC PO Log (or other Business Unit Log)

Yes Yes Yes Yes


Business Objectives

Specific results to be achieved in order to effectively respond to the business need (e.g., Institutionalize Project Mgt "best practices")

Yes Yes


Business Benefits Specific benefits resulting from business objectives being achieved (e.g., More predictable and consistent delivery of services)

Yes Yes


Project Objectives Specific objectives of the project itself which lead directly to accomplishment of the business objectives (e.g., Resource optimization capability)

Yes Yes


Strategic Alignment

UNT / CITC strategic objectives supported by the project

Yes Yes Yes


Deliverables In Scope

Deliverables considered part of the boundaries of the project

Yes Yes

4/11/2023




Deliverables Out of Scope

Deliverables NOT considered part of the boundaries of the project

Yes Yes


Organizational Impacts

Organizations/specific departments impacted or participating in the project and the corresponding impact/participation

Yes Yes


Related Projects / Systems

Other projects or existing systems that have a relationship to the project and the associated dependency

Yes Yes


Preliminary Cost Estimate

Preliminary cost estimates for software, hardware, services, etc. (more rigorous, detailed estimate performed during Planning Review Gate). THIS MAY NEED TO INCLUDE A PRELIMINARY FIGURE FOR QUANTITATIVE BENEFITS IN ORDER TO PROVIDE A PRELIMINARY COST/BENEFIT ANALYSIS

Yes Yes Yes


Preliminary Milestones

Preliminary milestones for high-level phases/tasks of the project (detailed schedule developed during Planning Review Gate)

Yes Yes


Project Constraints Limits in terms of people, money, time, and equipment that, although may be adjusted up or down, are considered fixed resources (e.g., development activity must be completed by April 2)

Yes Yes


Project Assumptions

Events and circumstances relevant to the project assumed to be true that are essential for success (e.g., adequate hardware is currently a available to support the upgrade)

Yes Yes


Critical Success Factors

What must happen / be accomplished in order for this project to be considered a success

Yes Yes


Project Organization

Visio chart depicting project organization (e.g., reporting structure to the project manager, sponsor, executive sponsor, steering committee, etc.)

Yes Yes


Roles & Responsibilities

Roles & responsibilities specific to the project (e.g., project manager, sponsor, functional lead, etc.)

Yes Yes

4/11/2023




Key Stakeholders Key stakeholders for the project per the roles & responsibilities defined for the project

Yes Yes Yes

56 Initiation Steering Committee w/Exec Sponsor

N/A Require steering Committee w/Exec Sponsor Yes Yes

57 Initiation Online Risk Evaluator

N/A Initial Risk Evaluation Yes Yes

58 Initiation Project Team Workspace

N/A Central Repository/ Workspace for project team collaboration on issues, risks, scope mgt, docs, etc. (e.g., SharePoint)

Yes Yes Yes

59 Initiation Initiation Review Gate Approval

N/A Sign-Off Yes Yes Yes

60 Planning Product Scope Statement

Exec Summary Brief overview of the project Yes Yes


In Scope Specific deliverables / functionality that will be included in the product delivered by the project

Yes Yes


Out of Scope Specific deliverables / functionality that will NOT be included in the product delivered by the project

Yes Yes


Acceptance Criteria

What is required for Customer Acceptance of the delivered product(s)

Yes Yes Yes


Risk Mgt Approach Approach to Risk Mgt used by the project Yes Yes


Issue Mgt Approach

Approach to Issue Mgt used by the project Yes Yes


Scope Change Mgt Approach

Approach to Scope Change Mgt used by the project

Yes Yes Yes


Communication Mgt Approach

Approach to Communication Mgt used by the project

Yes Yes

4/11/2023




Procurement Mgt Approach

Approach to Procurement Mgt used by the project Yes Yes


Resource Mgt Approach

Approach to Resource Mgt used by the project Yes Yes

70 Planning Procurement Plan

Procurement Statement

In general, what products or services are being considered for procurement and why

Yes Yes


Estimated Cost Estimated total cost of procurement, including confidence limits for the estimate (e.g., plus/minus dollars or percent of estimate).

Yes Yes Yes


Vendor Selection What general approach the Project Team will take to select a product or vendor (e.g., RFI, RFP, etc.)

Yes Yes


Procurement Description

In specific terms, what items will be procured and under what conditions (e.g., application module(s), specific hardware, specific misc. software, specific services, etc.)

Yes Yes


Selection Process & Criteria

The selection process and general selection criteria, including any analytical tool that will be used

Yes Yes


Procurement Team All stakeholders who are involved in the Procurement Process, along with contact information and a description of their Procurement Role (e.g., Project Manager, Legal, PPS, Contract Administrator, CITC Administrative Services, etc.)

Yes Yes


Contract Type(s) Which type of contract will be used with each procurement if applicable (e.g., Time and Materials, Fixed Price, Not-To-Exceed, etc.)

Yes Yes


Contract Standards Standards for documentation that will be used for each contract (e.g., if reimbursement is based on vendor performance, is the approval signature for each deliverable sufficient or must a quality review be done?)

Yes Yes

78 Planning Resource Plan Project Team Size High-level estimate of project team size requirements

Yes Yes Yes

4/11/2023



79 Planning Resource Plan Required Skill Sets Required skills by project deliverable (e.g., deliverable, resource type, source, estimated cost, quantity)

Yes Yes

80 Planning Resource Plan Non-Labor Resources

Non-labor resources required for the project (e.g., workspace, computers, test equipment)

Yes Yes

81 Planning Resource Plan Resource Staffing Plan

Outline anticipated resource needs throughout the project life cycle

Yes Yes

82 Planning Resource Plan Project Team Visio chart depicting project organization (e.g., reporting structure to the project manager, sponsor, executive sponsor, steering committee, etc.)

Yes Yes Yes

83 Planning Resource Plan Resource Assumptions

Events and circumstances relevant to Resource Allocation assumed to be true that are essential for success (e.g., Application development resources will be dedicated to the project; current system support will be backfilled)

Yes Yes

84 Planning Resource Plan Resource Risks and Mitigations

Resource risks and mitigations (e.g., add time to tasks for which assigned resources have known skill deficiencies, add a percent multiplier to the project schedule for individual resources as appropriate, etc.)

Yes Yes

85 Planning BASELINED Detailed Schedule

N/A All tasks and milestones of a project Yes Yes

86 Planning BASELINED Milestone Schedule

N/A Milestones only Yes Yes

87 Planning Refined Detailed Budget (cost/benefit analysis)

N/A Detailed estimated budget (INCLUDING ON-GOING MAINTENANCE COSTS AND COST/BENEFIT ANALYSIS?)

Yes Yes

88 Planning Security Checklist (TBD)

N/A Checklist to ensure that information security implications have been carefully considered and acted upon as applicable

Yes Yes Yes

89 Planning Risk Assessment

N/A This is an exercise which affords the project manager the ability to forecast specific risks for the project risk log and prescribe fixes ahead of

Yes Yes

4/11/2023



time should they occur90 Planning Organizational

Chg Mgt PlanOrganizational Chg Mgt Scope

Identify the scope of the change management effort

Yes Yes

91 Planning Organizational Chg Mgt Plan

Communication Objectives

Ensure that communication among key players is effective

Yes Yes


Training Objectives Ensure that staff is fully prepared before they are expected to perform new duties

Yes Yes


Approach and Resources

Recommended tools for effective change management

Yes Yes

94 Planning Quality Mgt Plan

Project Quality Plan Purpose

Project quality plan's purpose and how it meets specific project needs

Yes Yes


Quality Mgt Method

Project overview, standards, tools, quality mgr responsibilities

Yes Yes


Project Quality Assurance

Procedures, monitoring processes, in-process quality monitoring, etc.

Yes Yes


Project Quality Control

Deliverables, procedures, deliverable test & acceptance processes, and acceptance criteria

Yes Yes


Identified Quality Audits & Quality Reviews

Reviews, planned dates, quality review auditors, comments

Yes Yes


Management Escalation Plan

Plan for escalating unresolved quality noncompliance issues up the management chain

Yes Yes


Quality Team Roles & Responsibilities

Quality-related responsibilities of the project team and specific task-related quality responsibilities, including responsibility for specific acceptance tests and project audits

Yes Yes


Quality Plan Audit Log

Quality-related issues and resolutions resulting from quality audits and reviews

Yes Yes

4/11/2023



102 Planning Communication Plan

Reports Project Reporting deliverables and descriptions, delivery method, frequency, owner, and audience

Yes Yes Yes


Presentations Project Presentations deliverables and descriptions, delivery method, frequency, owner, and audience

Yes Yes


Project Announcements

Project Announcements deliverables and descriptions, delivery method, frequency, owner, and audience

Yes Yes


Reviews and Meetings

Project Reviews and Meetings deliverables and descriptions, delivery method, frequency, owner, and audience

Yes Yes


Team Morale Project Team Morale deliverables and descriptions, delivery method, frequency, owner, and audience

Yes Yes

107 Planning Planning Review Gate Approval

N/A Sign-Off Yes Yes Yes Yes

108 Implementation Project Status Project State New, Active, Completed, On Hold, Cancelled Yes Yes Yes Yes

109 Implementation Project Status Project Stage Gate Business Justification/Initiation, Planning, Implementation, Benefits Realization/Closeout

Yes Yes Yes Yes

110 Implementation Project Status Schedule Status No baseline, Late, Late by > 5 days, On schedule, Ahead of schedule

Yes Yes Yes Yes

111 Implementation Project Status Schedule Status Note

Note about schedule status Yes Yes Yes Yes

112 Implementation Project Status Budget Status No budget, Over budget, Over by >= 20%, On budget, Under budget

Yes Yes Yes

113 Implementation Project Status Budget Status Note

Note about budget status Yes Yes Yes

114 Implementation Project Status Scope Status Controlled, Caution, Critical, Unspecified Yes Yes Yes

4/11/2023



115 Implementation Project Status Scope Status Note Note about scope status Yes Yes Yes

116 Implementation Project Status Resource Status Controlled, Caution, Critical, Unspecified Yes Yes

117 Implementation Project Status Resource Status Note

Note about resource status Yes Yes

118 Implementation Project Status Overall Status Controlled, Caution, Critical, Unspecified Yes Yes Yes Yes

119 Implementation Project Status Overall Status Note Note about overall status Yes Yes Yes Yes

120 Implementation SharePoint Risks Log

N/A This is a TOOL and not a DELIVERABLE, but provided for process requirement purposes

Yes Yes

121 Implementation SharePoint Issues Log


Yes Yes

122 Implementation SharePoint Scope Mgt Log


Yes Yes

123 Implementation Project-Specific Deliverables

N/A These can be anything from supporting documentation (training guides, database design, etc.) to the delivered product itself (e.g., working system). Example attached for explanation purposes because these are prescribed by each individual project

Yes Yes

124 Implementation (Formal) Project Status Report


Yes Yes

125 Implementation Updated planning documents

N/A Keep documents created in the Planning Review Gate up-to-date

Yes Yes Yes Yes

4/11/2023



126 Implementation Implementation Review Gate Approval

N/A Sign-Off Yes Yes Yes Yes

127 Benefits Realization

Business Outcomes Review

Project Background Overview

Brief description of the project background Yes Yes



Project Highlights and Best Practices

Project highlights (i.e., significant accomplishments that "showcase" the project) and "best practices" that proved to be useful during the course of the project)

Yes Yes



Project Closeout Synopsis

Why the project is being closed (e.g., all project objectives and deliverables have been met; Loss of funding; Shift in strategy)

Yes Yes Yes



Business Objectives Performance

Comparison if actual project performance to business objectives

Yes Yes



Project Objectives Performance

Comparison if actual project performance to project objectives

Yes Yes



Critical Success Factors Performance

Project performance in terms of targeted critical success factors

Yes Yes



Milestone and Deliverables Performance

Actual performance of project milestones and corresponding deliverables

Yes Yes



Schedule Performance

Comparison of actual start and finish dates to the baseline schedule

Yes Yes



Budget Performance

Comparison of actual costs to the project budget Yes Yes



Metrics Performance Recommendations

Metrics performance recommendations for the future

Yes Yes



Issue Mgt Issues still outstanding at the end of the project Yes Yes

4/11/2023





Risk Mgt Risks that were mitigated throughout the project and a list of risks that are outstanding at the end of the project

Yes Yes



Communication Mgt

How well did the communication process work? Yes Yes



Customer Expectation Mgt

How well were customer expectations met? Yes Yes



Lessons Learned Significant successes and shortcomings to remember for the future

Yes Yes



Post-Project Tasks Outstanding task for the project Yes Yes



Project Closeout Recommendations

List of recommendations arising from review of closure tasks

Yes Yes


Lessons Learned

N/A More specific documentation on "Lessons Learned" Yes Yes


Benefits Realization Review Gate Approval

N/A Sign-Off Yes Yes

4/11/2023

Project Management Framework Handbook

Documents

Transcript of Project Management Framework Handbook