• Share
  • Email
  • Embed
  • Like
  • Save
  • Private Content
Project Management Framework Handbook
 

Project Management Framework Handbook

on

  • 9,345 views

 

Statistics

Views

Total Views
9,345
Views on SlideShare
9,320
Embed Views
25

Actions

Likes
6
Downloads
953
Comments
1

2 Embeds 25

http://www.scoop.it 18
http://baridoo.com 7

Accessibility

Categories

Upload Details

Uploaded via as Microsoft Word

Usage Rights

© All Rights Reserved

Report content

Flagged as inappropriate Flag as inappropriate
Flag as inappropriate

Select your reason for flagging this presentation as inappropriate.

Cancel

11 of 1 previous next

  • Full Name Full Name Comment goes here.
    Are you sure you want to
    Your message goes here
    Processing…
  • You can get PMBOK 5th edition based complete & 'brain-friendly' PMP exam notes for free on www.PMExamSmartNotes.com. Also, sign up for your free PMP Study Blueprint to fast track your PMP preparation efforts.
    Are you sure you want to
    Your message goes here
    Processing…
Post Comment
Edit your comment

    Project Management Framework Handbook Project Management Framework Handbook Document Transcript

    • 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 Added stage gate approval policy, table of Leatherbury 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..........................................................................................................................10 2.3.1 Define Business Need / Opportunity.............................................................................10 2.3.2 Define Business Objectives and Benefits.....................................................................10 2.3.3 Define Project Objectives.............................................................................................11 2.3.4 Identify Project Manager...............................................................................................12 2.3.5 Identify Sponsor...........................................................................................................13 2.3.6 Ensure Alignment with Strategic Direction....................................................................13 2.3.7 Define Project Scope....................................................................................................14 2.3.8 Develop Preliminary Budget and Milestones................................................................14 2.3.9 Identify Project Constraints and Assumptions..............................................................15 2.3.10 Develop Project Organization (Governance)..............................................................15 2.3.11 Identify and Engage Key Stakeholders.......................................................................16 2.3.12 Perform Initial Risk Evaluation....................................................................................16 2.4 Deliverables.....................................................................................................................17 2.4.1 Project Plan..................................................................................................................17 2.4.2 Project Charter.............................................................................................................17 2.4.3 Sign-Offs......................................................................................................................17 3 PLANNING REVIEW GATE......................................................................................................18 3.1 Overview.........................................................................................................................18 3.2 Critical Success Factors..................................................................................................19 3.3 Activities..........................................................................................................................20 3.3.1 Develop Product Scope Statement..............................................................................20 3.3.2 Develop Procurement Plan...........................................................................................20 3.3.3 Develop Resource Plan................................................................................................21 3.3.4 Create Schedule...........................................................................................................22 Page 2 6/3/2010
    • UNT Project Management Handbook 3.3.5 Refine Project Budget...................................................................................................23 3.3.6 Perform Risk Assessment............................................................................................24 3.3.7 Develop Organizational Change Mgt Plan....................................................................24 3.3.8 Develop Quality Management Plan..............................................................................24 3.3.9 Develop Communication Plan......................................................................................25 3.4 Deliverables.....................................................................................................................26 3.4.1 Project Plan..................................................................................................................26 3.4.2 Sign-Off........................................................................................................................26 4 SOLICITATION AND CONTRACTING REVIEW GATE (MAJOR PROJECTS ONLY)............27 4.1 Overview.........................................................................................................................27 4.2 Activities..........................................................................................................................27 4.2.1 Deliverables..................................................................................................................27 4.2.2 Sign-Off........................................................................................................................27 5 IMPLEMENTATION REVIEW GATE.........................................................................................28 5.1 Overview.........................................................................................................................28 5.2 Critical Success Factors..................................................................................................29 5.3 Activities..........................................................................................................................30 5.3.1 Execute Procurement Plan...........................................................................................30 5.3.2 Manage Schedule........................................................................................................30 5.3.3 Document Work Results...............................................................................................31 5.3.4 Manage Quality............................................................................................................32 5.3.5 Manage Costs..............................................................................................................32 5.3.6 Manage Risks...............................................................................................................33 5.3.7 Manage Issues.............................................................................................................35 5.3.8 Manage Scope.............................................................................................................36 5.3.9 Manage Organizational Change...................................................................................37 5.3.10 Communicate Information..........................................................................................37 5.3.11 Conduct Status Review Meetings...............................................................................38 5.3.12 Review Project Checkpoints.......................................................................................39 5.3.13 Administer Contracts / Vendors..................................................................................39 5.3.14 Update Project Planning Documents..........................................................................40 5.4 Deliverables.....................................................................................................................41 5.4.1 (Formal) Project Status Reports...................................................................................41 5.4.2 Updated Planning Documents......................................................................................41 5.4.3 Project-Specific Deliverables........................................................................................41 5.4.4 Sign-Off........................................................................................................................41 6 BENEFITS REALIZATION / CLOSEOUT REVIEW GATE.......................................................42 6.1 Overview.........................................................................................................................42 6.2 Critical Success Factors..................................................................................................42 6.3 Activities..........................................................................................................................43 6.3.1 Conduct Business Outcomes Review Meeting.............................................................43 Page 3 6/3/2010
    • UNT Project Management Handbook 6.3.2 Conduct Lessons Learned Meeting..............................................................................43 6.3.3 Conduct Contract Closure............................................................................................44 6.3.4 Conduct Knowledge Transfer.......................................................................................45 6.4 Deliverables.....................................................................................................................46 6.4.1 Business Outcomes Review Document........................................................................46 6.4.2 Lessons Learned Report..............................................................................................46 6.4.3 Sign-Off........................................................................................................................46 7 KEY ROLES AND RESPONSIBILITIES...................................................................................47 7.1 Overview.........................................................................................................................47 7.2 Sponsor...........................................................................................................................48 7.2.1 General Functions........................................................................................................48 7.2.2 Business Justification/Initiation Review Gate...............................................................48 7.2.3 Planning Review Gate..................................................................................................48 7.2.4 Implementation Review Gate.......................................................................................48 7.2.5 Benefits Realization/Closeout Review Gate.................................................................48 7.3 Project Manager..............................................................................................................49 7.3.1 Overview......................................................................................................................49 7.3.2 General Functions........................................................................................................49 7.3.3 Business Justification/Initiation Review Gate...............................................................49 7.3.4 Planning Review Gate..................................................................................................49 7.3.5 Implementation Review Gate.......................................................................................49 7.3.6 Benefits Realization/Closeout Review Gate.................................................................50 7.4 Steering Committee.........................................................................................................51 7.4.1 Overview......................................................................................................................51 7.4.2 General Functions........................................................................................................51 7.4.3 Business Justification/Initiation Review Gate...............................................................51 7.4.4 Planning Review Gate..................................................................................................51 7.4.5 Implementation Review Gate.......................................................................................51 7.4.6 Benefits Realization/Closeout Review Gate.................................................................51 7.5 Project Team...................................................................................................................52 7.5.1 Overview......................................................................................................................52 7.5.2 General Functions........................................................................................................52 7.5.3 Business Justification/Initiation Review Gate...............................................................52 7.5.4 Planning Review Gate..................................................................................................52 7.5.5 Implementation Review Gate.......................................................................................52 7.5.6 Benefits Realization/Closeout Review Gate.................................................................52 8 APPENDIX A – PROJECT APPROVAL STRUCTURE............................................................53 9 APPENDIX B – PROJECT CLASSIFICATIONS.......................................................................54 Page 4 6/3/2010
    • UNT Project Management Handbook 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. Page 5 6/3/2010
    • UNT Project Management Handbook 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/Initiation 2. Project Planning 3. Soliciting and Contracting 4. Project Implementation 5. 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. Page 6 6/3/2010
    • UNT Project Management Handbook 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. Page 7 6/3/2010
    • UNT Project Management Handbook 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 Page 8 6/3/2010
    • UNT Project Management Handbook 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 Page 9 6/3/2010
    • UNT Project Management Handbook 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. Page 10 6/3/2010
    • UNT Project Management Handbook 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. Page 11 6/3/2010
    • UNT Project Management Handbook 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 Page 12 6/3/2010
    • UNT Project Management Handbook 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 Page 13 6/3/2010
    • UNT Project Management Handbook 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. Page 14 6/3/2010
    • UNT Project Management Handbook 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. Page 15 6/3/2010
    • UNT Project Management Handbook 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. Page 16 6/3/2010
    • UNT Project Management Handbook 2.4 Deliverables 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. 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. Page 17 6/3/2010
    • UNT Project Management Handbook 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. Page 18 6/3/2010
    • UNT Project Management Handbook 3.2 Critical Success Factors • Identification of Project Manager with a track record of success • Ensure that key resources are available as required by the Project Plan Page 19 6/3/2010
    • UNT Project Management Handbook 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) Page 20 6/3/2010
    • UNT Project Management Handbook 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. Page 21 6/3/2010
    • UNT Project Management Handbook 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) Page 22 6/3/2010
    • UNT Project Management Handbook 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. Page 23 6/3/2010
    • UNT Project Management Handbook 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. Page 24 6/3/2010
    • UNT Project Management Handbook 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. Page 25 6/3/2010
    • UNT Project Management Handbook 3.4 Deliverables 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. 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. Page 26 6/3/2010
    • UNT Project Management Handbook 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 See DIR Project Delivery Framework: http://www.dir.state.tx.us/pubs/framework/gate3/index.htm 4.2.2 Sign-Off See DIR Project Delivery Framework: http://www.dir.state.tx.us/pubs/framework/gate3/index.htm Page 27 6/3/2010
    • UNT Project Management Handbook 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. Page 28 6/3/2010
    • UNT Project Management Handbook 5.2 Critical Success Factors • 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 Page 29 6/3/2010
    • UNT Project Management Handbook 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. Page 30 6/3/2010
    • UNT Project Management Handbook 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 Page 31 6/3/2010
    • UNT Project Management Handbook 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. Page 32 6/3/2010
    • UNT Project Management Handbook 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) Page 33 6/3/2010
    • UNT Project Management Handbook 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. Page 34 6/3/2010
    • UNT Project Management Handbook 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. Page 35 6/3/2010
    • UNT Project Management Handbook 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). Page 36 6/3/2010
    • UNT Project Management Handbook 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. Page 37 6/3/2010
    • UNT Project Management Handbook 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. Page 38 6/3/2010
    • UNT Project Management Handbook 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. Page 39 6/3/2010
    • UNT Project Management Handbook 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. Page 40 6/3/2010
    • UNT Project Management Handbook 5.4 Deliverables 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. 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. Page 41 6/3/2010
    • UNT Project Management Handbook 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. 6.2 Critical Success Factors • Customer acceptance criteria met • Business objectives are achieved • Anticipated benefits are achieved • Project objectives are achieved Page 42 6/3/2010
    • UNT Project Management Handbook 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 Page 43 6/3/2010
    • UNT Project Management Handbook 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 Page 44 6/3/2010
    • UNT Project Management Handbook 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 Page 45 6/3/2010
    • UNT Project Management Handbook 6.4 Deliverables 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. 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. Page 46 6/3/2010
    • UNT Project Management Handbook 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. Page 47 6/3/2010
    • UNT Project Management Handbook 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 Page 48 6/3/2010
    • UNT Project Management Handbook 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. 7.3.2 General Functions • 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 7.3.3 Business Justification/Initiation Review Gate • Defines project success criteria • Documents project constraints • Documents project assumptions • Conducts cost-benefit analyses • Develops Project Charter 7.3.4 Planning Review Gate • 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 7.3.5 Implementation Review Gate • 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 Page 49 6/3/2010
    • UNT Project Management Handbook 7.3.6 Benefits Realization/Closeout Review Gate • 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 Page 50 6/3/2010
    • UNT Project Management Handbook 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. 7.4.2 General Functions • 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) 7.4.3 Business Justification/Initiation Review Gate • Reviews / approves Project Charter 7.4.4 Planning Review Gate • Reviews / approves the Project Plan 7.4.5 Implementation Review Gate • 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 7.4.6 Benefits Realization/Closeout Review Gate • Attends Business Outcomes Review Meeting • Signs-off on Business Outcomes Review Document, if key Stakeholder • Attends Lessons Learned Meeting Page 51 6/3/2010
    • UNT Project Management Handbook 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. 7.5.2 General Functions • Identifies technical solution alternatives • Implements solution within budgeted cost and schedule • Supports Project Planning and tracking 7.5.3 Business Justification/Initiation Review Gate • Provides estimates for developing products • Ensures that requirements are feasible and appropriate for available resources • Analyzes requirements for completeness, consistency, and clarity 7.5.4 Planning Review Gate • 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 7.5.5 Implementation Review Gate • 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 7.5.6 Benefits Realization/Closeout Review Gate • Participates in Business Outcomes Review Meeting, as appropriate • Participates in Lessons Learned Meeting, as appropriate Page 52 6/3/2010
    • UNT Project Management Handbook • Identifies ways to improve project processes • Turns over all project-related documentation to the Project Manager for archiving 8 APPENDIX A – PROJECT APPROVAL STRUCTURE Final Approval Authority by Project Size* Project Stage Governance Minor Small Medium Large Step Business Project Plan Business Business Business Business Justification/ Approval Unit Unit Unit Unit Initiation Charter Business Business ITSC ITSC Approval Unit Unit Planning Project Plan Business Business ITCPG ITCPG Approval Unit Unit Implementation- Business Business ITCPG ITCPG Specific Unit Unit Planning Document Implementation Approval Project Business Business ITCPG ITSC Progress Unit Unit Review(s) Benefits Business Business Business ITCPG ITSC Realization/ Outcomes Unit Unit Closeout Review Approval *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 Instruction o EIS Program Management o Communications o Standards & Policy o Student Computing • ITSC: – the Information Technology Steering Committee. The ITSC, as defined by Policy xx.x: Information Technology Advisory Committees at UNT Page 53 6/3/2010
    • UNT Project Management Handbook 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 Project Request Project Name Short name for the project (same as used in EPM Yes Yes Yes Yes Justification system) 2 Business Project Request Customer Dept Customer department requesting project Yes Yes Yes Yes Justification 3 Business Project Request Customer Priority? Low, Medium, High Yes Yes Yes Yes Justification 4 Business Project Request Project Description Concise description of the project which will result Yes Yes Yes Yes Justification in the desired product(s) 5 Business Project Request Business Need Concise descriptions of the immediate business Yes Yes Yes Justification 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 6 Business Project Request Alternatives Business alternatives to invoking project Yes Yes Yes Justification 7 Business Project Request Product Owner Customer representative who takes delivery of the Yes Yes Yes Yes Justification (Requestor) product produced by the project (e.g., Walter Bowen for CRM) 8 Business Project Request Funding Identified, Not Identified, Not Needed Yes Yes Yes Justification Identification Page 54 6/3/2010
    • UNT Project Management Handbook Line # Review Gate Item Component Description Minor Small Medium Large 9 Business Project Request UNTS Affiliate(s) UNT,HSC,DAL,SYS,UCD Yes Yes Yes Yes Justification Impacted 10 Business Project Request Proposed Start Customer proposed start date Yes Yes Yes Yes Justification 11 Business Project Request Proposed Finish Customer proposed finish date Yes Yes Yes Yes Justification 12 Business Project Request Mandate Type Internal (UNTS) / External (State) Yes Yes Yes Justification 13 Business Project Request Mandated By Internal or external organization issuing mandate Yes Yes Yes Justification (e.g., DIR) 14 Business Project Request Deadline Hard deadline if exists (internally or externally Yes Yes Yes Justification mandated) 15 Business Project Request Impact if not e.g., Non-compliance w/DIR PM initiative Yes Yes Yes Justification implemented 16 Business Assessment Magnitude <= 1 wk,<= 1 mo,<= 3 mo,<= 6 mo,<= 12 Yes Yes Yes Justification mo,> 12 mo 17 Business Assessment Rank Rank within the project portfolio (1-n) Yes Yes Yes Justification 18 Business Assessment Capital Forecast Initially forecasted capital expense Yes Yes Yes Yes Justification (Capital Cost) 19 Business Assessment Labor Hrs Forecast Initially forecasted total labor hours to complete Yes Yes Yes Yes Justification (Labor Hours) project 20 Business Assessment Project Category New Initiative, Enhancement Yes Yes Yes Justification 21 Business Assessment Service Area The particular service area within CITC that is tied Yes Yes Justification to the project (or operational activity) Page 55 6/3/2010
    • UNT Project Management Handbook Line # Review Gate Item Component Description Minor Small Medium Large 22 Business Assessment Project Minor, Small, Medium, Large Yes Yes Yes Yes Justification Classification 23 Business Assessment Risk Low, Medium, High Yes Yes Justification 24 Business Assessment Product/Application Product or application system tied to the project Yes Yes Justification 25 Business Portfolio Portfolio Approval Proposed, Approved, Rejected Yes Yes Yes Yes Justification Approval Status 26 Business Portfolio Disapproved Business reason the project was not approved for Yes Yes Yes Yes Justification Approval Reason inclusion in the project portfolio 27 Intentionally left blank 28 Initiation Full Business Schedule Flexibility Low, Medium, High Yes Yes Yes Case/Project Charter 29 Initiation Full Business Scope Flexibility Low, Medium, High Yes Yes Yes Case/Project Charter 30 Initiation Full Business Resource Flexibility Low, Medium, High Yes Yes Yes Case/Project Charter 31 Initiation Full Business Project Manager The individual within CITC who is responsible for Yes Yes Yes Yes Case/Project the day-to-day management and delivery of the Charter project (e.g., Andy Novak for EPM) 32 Initiation Full Business Project Sponsor The CITC Senior Manager (usually a Director) Yes Yes Yes Yes Case/Project responsible for strategic direction and financial Charter support of the project (e.g., Charlotte Russell for EPM) Page 56 6/3/2010
    • UNT Project Management Handbook Line # Review Gate Item Component Description Minor Small Medium Large 33 Initiation Full Business Exec Sponsor Top-level executive who provides support for the Yes Yes Case/Project Project Sponsor and the Project Manager and is Charter 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 business unit head who is championing the initiative 34 Initiation Full Business Oversight External oversight body having management Yes Yes Case/Project Authority control over the project (e.g., CITC Mgt for EPM) Charter 35 Initiation Full Business Performer Group responsible for project delivery Yes Yes Yes Yes Case/Project Charter 36 Initiation Full Business Work Type Project, Operations Yes Yes Yes Yes Case/Project Charter EPM 37 Initiation Full Business Operations Type Support, Minor Enhancement Yes Yes Yes Yes Case/Project Charter 38 Initiation Full Business DIR Flag Project meets DIR Major project criteria Yes Case/Project Charter 39 Initiation Full Business Business Unit Cross-reference that associates an EPM Project Yes Yes Yes Yes Case/Project Purchasing Project with one (or more?) Project Numbers that exist in Charter Number (if the CITC PO Log (or other Business Unit Log) applicable) 40 Initiation Full Business Business Specific results to be achieved in order to Yes Yes Case/Project Objectives effectively respond to the business need (e.g., Charter Institutionalize Project Mgt "best practices") 41 Initiation Full Business Business Benefits Specific benefits resulting from business objectives Yes Yes Case/Project being achieved (e.g., More predictable and Charter consistent delivery of services) Page 57 6/3/2010
    • UNT Project Management Handbook Line # Review Gate Item Component Description Minor Small Medium Large 42 Initiation Full Business Project Objectives Specific objectives of the project itself which lead Yes Yes Case/Project directly to accomplishment of the business Charter objectives (e.g., Resource optimization capability) 43 Initiation Full Business Strategic UNT / CITC strategic objectives supported by the Yes Yes Yes Case/Project Alignment project Charter 44 Initiation Full Business Deliverables In Deliverables considered part of the boundaries of Yes Yes Case/Project Scope the project Charter 45 Initiation Full Business Deliverables Out of Deliverables NOT considered part of the Yes Yes Case/Project Scope boundaries of the project Charter 46 Initiation Full Business Organizational Organizations/specific departments impacted or Yes Yes Case/Project Impacts participating in the project and the corresponding Charter impact/participation 47 Initiation Full Business Related Projects / Other projects or existing systems that have a Yes Yes Case/Project Systems relationship to the project and the associated Charter dependency 48 Initiation Full Business Preliminary Cost Preliminary cost estimates for software, hardware, Yes Yes Yes Case/Project Estimate services, etc. (more rigorous, detailed estimate Charter 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 49 Initiation Full Business Preliminary Preliminary milestones for high-level phases/tasks Yes Yes Case/Project Milestones of the project (detailed schedule developed during Charter Planning Review Gate) 50 Initiation Full Business Project Constraints Limits in terms of people, money, time, and Yes Yes Case/Project equipment that, although may be adjusted up or Charter down, are considered fixed resources (e.g., development activity must be completed by April 2) 51 Initiation Full Business Project Events and circumstances relevant to the project Yes Yes Case/Project Assumptions assumed to be true that are essential for success Charter (e.g., adequate hardware is currently a available to support the upgrade) Page 58 6/3/2010
    • UNT Project Management Handbook Line # Review Gate Item Component Description Minor Small Medium Large 52 Initiation Full Business Critical Success What must happen / be accomplished in order for Yes Yes Case/Project Factors this project to be considered a success Charter 53 Initiation Full Business Project Visio chart depicting project organization (e.g., Yes Yes Case/Project Organization reporting structure to the project manager, Charter sponsor, executive sponsor, steering committee, etc.) 54 Initiation Full Business Roles & Roles & responsibilities specific to the project Yes Yes Case/Project Responsibilities (e.g., project manager, sponsor, functional lead, Charter etc.) 55 Initiation Full Business Key Stakeholders Key stakeholders for the project per the roles & Yes Yes Yes Case/Project responsibilities defined for the project Charter 56 Initiation Steering N/A Require steering Committee w/Exec Sponsor Yes Yes Committee w/Exec Sponsor 57 Initiation Online Risk N/A Initial Risk Evaluation Yes Yes Evaluator 58 Initiation Project Team N/A Central Repository/ Workspace for project team Yes Yes Yes Workspace collaboration on issues, risks, scope mgt, docs, etc. (e.g., SharePoint) 59 Initiation Initiation N/A Sign-Off Yes Yes Yes Review Gate Approval 60 Planning Product Scope Exec Summary Brief overview of the project Yes Yes Statement 61 Planning Product Scope In Scope Specific deliverables / functionality that will be Yes Yes Statement included in the product delivered by the project 62 Planning Product Scope Out of Scope Specific deliverables / functionality that will NOT Yes Yes Statement be included in the product delivered by the project 63 Planning Product Scope Acceptance Criteria What is required for Customer Acceptance of the Yes Yes Yes Statement delivered product(s) Page 59 6/3/2010
    • UNT Project Management Handbook Line # Review Gate Item Component Description Minor Small Medium Large 64 Planning Product Scope Risk Mgt Approach Approach to Risk Mgt used by the project Yes Yes Statement 65 Planning Product Scope Issue Mgt Approach to Issue Mgt used by the project Yes Yes Statement Approach 66 Planning Product Scope Scope Change Mgt Approach to Scope Change Mgt used by the Yes Yes Yes Statement Approach project 67 Planning Product Scope Communication Approach to Communication Mgt used by the Yes Yes Statement Mgt Approach project 68 Planning Product Scope Procurement Mgt Approach to Procurement Mgt used by the project Yes Yes Statement Approach 69 Planning Product Scope Resource Mgt Approach to Resource Mgt used by the project Yes Yes Statement Approach 70 Planning Procurement Procurement In general, what products or services are being Yes Yes Plan Statement considered for procurement and why 71 Planning Procurement Estimated Cost Estimated total cost of procurement, including Yes Yes Yes Plan confidence limits for the estimate (e.g., plus/minus dollars or percent of estimate). 72 Planning Procurement Vendor Selection What general approach the Project Team will take Yes Yes Plan to select a product or vendor (e.g., RFI, RFP, etc.) 73 Planning Procurement Procurement In specific terms, what items will be procured and Yes Yes Plan Description under what conditions (e.g., application module(s), specific hardware, specific misc. software, specific services, etc.) 74 Planning Procurement Selection Process The selection process and general selection Yes Yes Plan & Criteria criteria, including any analytical tool that will be used Page 60 6/3/2010
    • UNT Project Management Handbook Line # Review Gate Item Component Description Minor Small Medium Large 75 Planning Procurement Procurement Team All stakeholders who are involved in the Yes Yes Plan 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.) 76 Planning Procurement Contract Type(s) Which type of contract will be used with each Yes Yes Plan procurement if applicable (e.g., Time and Materials, Fixed Price, Not-To-Exceed, etc.) 77 Planning Procurement Contract Standards Standards for documentation that will be used for Yes Yes Plan 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?) 78 Planning Resource Plan Project Team Size High-level estimate of project team size Yes Yes Yes requirements 79 Planning Resource Plan Required Skill Sets Required skills by project deliverable (e.g., Yes Yes deliverable, resource type, source, estimated cost, quantity) 80 Planning Resource Plan Non-Labor Non-labor resources required for the project (e.g., Yes Yes Resources workspace, computers, test equipment) 81 Planning Resource Plan Resource Staffing Outline anticipated resource needs throughout the Yes Yes Plan project life cycle 82 Planning Resource Plan Project Team Visio chart depicting project organization (e.g., Yes Yes Yes reporting structure to the project manager, sponsor, executive sponsor, steering committee, etc.) 83 Planning Resource Plan Resource Events and circumstances relevant to Resource Yes Yes Assumptions 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) 84 Planning Resource Plan Resource Risks and Resource risks and mitigations (e.g., add time to Yes Yes Mitigations tasks for which assigned resources have known skill deficiencies, add a percent multiplier to the project schedule for individual resources as appropriate, etc.) Page 61 6/3/2010
    • UNT Project Management Handbook Line # Review Gate Item Component Description Minor Small Medium Large 85 Planning BASELINED N/A All tasks and milestones of a project Yes Yes Detailed Schedule 86 Planning BASELINED N/A Milestones only Yes Yes Milestone Schedule 87 Planning Refined N/A Detailed estimated budget (INCLUDING ON- Yes Yes Detailed GOING MAINTENANCE COSTS AND COST/BENEFIT Budget ANALYSIS?) (cost/benefit analysis) 88 Planning Security N/A Checklist to ensure that information security Yes Yes Yes Checklist (TBD) implications have been carefully considered and acted upon as applicable 89 Planning Risk N/A This is an exercise which affords the project Yes Yes Assessment manager the ability to forecast specific risks for the project risk log and prescribe fixes ahead of time should they occur 90 Planning Organizational Organizational Chg Identify the scope of the change management Yes Yes Chg Mgt Plan Mgt Scope effort 91 Planning Organizational Communication Ensure that communication among key players is Yes Yes Chg Mgt Plan Objectives effective 92 Planning Organizational Training Objectives Ensure that staff is fully prepared before they are Yes Yes Chg Mgt Plan expected to perform new duties 93 Planning Organizational Approach and Recommended tools for effective change Yes Yes Chg Mgt Plan Resources management 94 Planning Quality Mgt Project Quality Project quality plan's purpose and how it meets Yes Yes Plan Plan Purpose specific project needs 95 Planning Quality Mgt Quality Mgt Project overview, standards, tools, quality mgr Yes Yes Plan Method responsibilities 96 Planning Quality Mgt Project Quality Procedures, monitoring processes, in-process Yes Yes Plan Assurance quality monitoring, etc. Page 62 6/3/2010
    • UNT Project Management Handbook Line # Review Gate Item Component Description Minor Small Medium Large 97 Planning Quality Mgt Project Quality Deliverables, procedures, deliverable test & Yes Yes Plan Control acceptance processes, and acceptance criteria 98 Planning Quality Mgt Identified Quality Reviews, planned dates, quality review auditors, Yes Yes Plan Audits & Quality comments Reviews 99 Planning Quality Mgt Management Plan for escalating unresolved quality Yes Yes Plan Escalation Plan noncompliance issues up the management chain 100 Planning Quality Mgt Quality Team Roles Quality-related responsibilities of the project team Yes Yes Plan & Responsibilities and specific task-related quality responsibilities, including responsibility for specific acceptance tests and project audits 101 Planning Quality Mgt Quality Plan Audit Quality-related issues and resolutions resulting Yes Yes Plan Log from quality audits and reviews 102 Planning Communication Reports Project Reporting deliverables and descriptions, Yes Yes Yes Plan delivery method, frequency, owner, and audience 103 Planning Communication Presentations Project Presentations deliverables and Yes Yes Plan descriptions, delivery method, frequency, owner, and audience 104 Planning Communication Project Project Announcements deliverables and Yes Yes Plan Announcements descriptions, delivery method, frequency, owner, and audience 105 Planning Communication Reviews and Project Reviews and Meetings deliverables and Yes Yes Plan Meetings descriptions, delivery method, frequency, owner, and audience 106 Planning Communication Team Morale Project Team Morale deliverables and descriptions, Yes Yes Plan delivery method, frequency, owner, and audience 107 Planning Planning N/A Sign-Off Yes Yes Yes Yes Review Gate Approval 108 Implementation Project Status Project State New, Active, Completed, On Hold, Cancelled Yes Yes Yes Yes Page 63 6/3/2010
    • UNT Project Management Handbook Line # Review Gate Item Component Description Minor Small Medium Large 109 Implementation Project Status Project Stage Gate Business Justification/Initiation, Planning, Yes Yes Yes Yes Implementation, Benefits Realization/Closeout 110 Implementation Project Status Schedule Status No baseline, Late, Late by > 5 days, On schedule, Yes Yes Yes Yes Ahead of schedule 111 Implementation Project Status Schedule Status Note about schedule status Yes Yes Yes Yes Note 112 Implementation Project Status Budget Status No budget, Over budget, Over by >= 20%, On Yes Yes Yes budget, Under budget 113 Implementation Project Status Budget Status Note about budget status Yes Yes Yes Note 114 Implementation Project Status Scope Status Controlled, Caution, Critical, Unspecified Yes Yes Yes 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 about resource status Yes Yes Note 118 Implementation Project Status Overall Status Controlled, Caution, Critical, Unspecified Yes Yes Yes Yes 119 Implementation Project Status Overall Status Note about overall status Yes Yes Yes Yes Note 120 Implementation SharePoint N/A This is a TOOL and not a DELIVERABLE, but Yes Yes Risks Log provided for process requirement purposes 121 Implementation SharePoint N/A This is a TOOL and not a DELIVERABLE, but Yes Yes Issues Log provided for process requirement purposes Page 64 6/3/2010
    • UNT Project Management Handbook Line # Review Gate Item Component Description Minor Small Medium Large 122 Implementation SharePoint N/A This is a TOOL and not a DELIVERABLE, but Yes Yes Scope Mgt Log provided for process requirement purposes 123 Implementation Project-Specific N/A These can be anything from supporting Yes Yes Deliverables 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 124 Implementation (Formal) N/A This is a TOOL and not a DELIVERABLE, but Yes Yes Project Status provided for process requirement purposes Report 125 Implementation Updated N/A Keep documents created in the Planning Yes Yes Yes Yes planning Review Gate up-to-date documents 126 Implementation Implementation N/A Sign-Off Yes Yes Yes Yes Review Gate Approval 127 Benefits Business Project Brief description of the project background Yes Yes Realization Outcomes Background Review Overview 128 Benefits Business Project Highlights Project highlights (i.e., significant Yes Yes Realization Outcomes and Best Practices accomplishments that "showcase" the project) and Review "best practices" that proved to be useful during the course of the project) 129 Benefits Business Project Closeout Why the project is being closed (e.g., all project Yes Yes Yes Realization Outcomes Synopsis objectives and deliverables have been met; Loss Review of funding; Shift in strategy) 130 Benefits Business Business Comparison if actual project performance to Yes Yes Realization Outcomes Objectives business objectives Review Performance 131 Benefits Business Project Objectives Comparison if actual project performance to Yes Yes Realization Outcomes Performance project objectives Review 132 Benefits Business Critical Success Project performance in terms of targeted critical Yes Yes Realization Outcomes Factors success factors Review Performance Page 65 6/3/2010
    • UNT Project Management Handbook Line # Review Gate Item Component Description Minor Small Medium Large 133 Benefits Business Milestone and Actual performance of project milestones and Yes Yes Realization Outcomes Deliverables corresponding deliverables Review Performance 134 Benefits Business Schedule Comparison of actual start and finish dates to the Yes Yes Realization Outcomes Performance baseline schedule Review 135 Benefits Business Budget Comparison of actual costs to the project budget Yes Yes Realization Outcomes Performance Review 136 Benefits Business Metrics Metrics performance recommendations for the Yes Yes Realization Outcomes Performance future Review Recommendations 137 Benefits Business Issue Mgt Issues still outstanding at the end of the project Yes Yes Realization Outcomes Review 138 Benefits Business Risk Mgt Risks that were mitigated throughout the project Yes Yes Realization Outcomes and a list of risks that are outstanding at the end Review of the project 139 Benefits Business Communication How well did the communication process work? Yes Yes Realization Outcomes Mgt Review 140 Benefits Business Customer How well were customer expectations met? Yes Yes Realization Outcomes Expectation Mgt Review 141 Benefits Business Lessons Learned Significant successes and shortcomings to Yes Yes Realization Outcomes remember for the future Review 142 Benefits Business Post-Project Tasks Outstanding task for the project Yes Yes Realization Outcomes Review 143 Benefits Business Project Closeout List of recommendations arising from review of Yes Yes Realization Outcomes Recommendations closure tasks Review 144 Benefits Lessons N/A More specific documentation on "Lessons Learned" Yes Yes Realization Learned 145 Benefits Benefits N/A Sign-Off Yes Yes Realization Realization Review Gate Page 66 6/3/2010
    • UNT Project Management Handbook Line # Review Gate Item Component Description Minor Small Medium Large Approval Page 67 6/3/2010