Appendix C - PennDOT IT Project Management Handbook.docx

IT Project Management Handbook

IT Project Management Handbook

Last Updated: 12/20/23 Version: 7.1 Prepared by: IED DC IT PMO Team IT Project Management Handbook

Table of Contents

Overview Introduction/ Purpose This document is intended to guide Project Managers (PM) who are implementing Infrastructure and Economic Development Delivery Center (IED DC) Information Technology (IT) Projects. Based on best practices and lessons learned, this guide provides a time-tested project management approach that yields successful results. This is a working document that provides step-by-step guidance and procedure for IED DC IT-PMs in the performance of their duties.

The overview section will provide background information for understanding IED DC IT Project development and execution process. The remainder of this handbook will provide specific details for carrying out the IT Project Management tasks.

About this Handbook This handbook provides specific direction regarding the management of IT Projects at IED DC. Links and/or references to standard IED DC templates are provided throughout this document.

Section 1 defines the foundational IT project management structures. These include:

· The Project Management Office (PMO)

· IED DC Project Management Methodology

· Portfolio and Project Management Tools

· Project Workspaces and Project Plans

· The IT Portfolio Process (the process flow of how projects are identified, approved, executed, and closed)

Section 2 focuses on Project Initiation

· Project Governance

· Project Charter

· Project Start-up Checklist

· Selecting Project Management Methodology

Section 3 focuses on Project Execution

· Detailed Project Planning

· Project Execution

· Project Monitoring and Control

· After Action Review

· Project Closure

Approved Document Templates described in the handbook are available on the IED DC IT PMO SharePoint Site at https://spportal.dot.pa.gov under Administration/PMO or the IED IT Portal at https://pagov.sharepoint.com/sites/IED-ITPortal. Links to these templates are also provided in the Related Documents/Templates table that follows each section. Document Templates that are not yet approved are listed in the Related Documents/Templates table but are not presented as links. Contact the PMO for access.

How to use this Handbook This handbook is designed to reflect the IED DC IT Project Development and Delivery Process (See Fig. 2, Page 12) and is intended to be a Project Manager’s companion for the initiation and execution of IT projects at IED DC. Section 1 describes the foundational project management structures that create order and consistency and help drive project success. Section 2 defines the steps and processes for project initiation. Section 3 describes the processes for monitoring and controlling project execution.

This handbook was produced by the IED DC IT Project Management Office (PMO). If you have questions concerning its content or use, or for help with any of the tasks or tools listed, please contact the PMO Administrator.

Section 1 - Foundational IT Project Management Structures and Definitions Project Management Structures and Definitions The Project Management Institute defines a Project as a temporary endeavor (fixed start and end dates) undertaken to develop a defined and unique product, service, or result. Definitions of IED DC Project Management structures are as follows:

The IT Project Management Office (PMO) The role of the PMO is to lead and aid project teams and improve IT project performance and results. The PMO ensures that all IT projects meet IED DC’s IT project management requirements, provides day-to-day project management, project management mentoring, fields questions, and uses MS Project Professional and Daptiv tools to monitor project work. The PMO reviews and approves all IT project workplans/schedules.

IED DC IT Project Management Methodologies A Project Management Methodology defines how projects are initiated, planned, managed, and closed. IED DC’s Information Systems and Technology Office/Bureau of Business and Service Management has chosen to utilize two methodologies: Iterative and Agile. The selection of the appropriate methodology for the project is made as a part of Project Initiation. Please see APPENDIX B - IED DC IT Project Management Methodologies for further detail.

Portfolio and Project Management Tools When conducting a project, IED DC uses the following Portfolio and Project Management tools:

· Daptiv - an OA/OIT web-based project and portfolio management tool that includes a time-tracking component. The entire BUS001 process flows through Daptiv which is considered the OA/OIT tool of record for the following:

· portfolio/project management

· resource planning and scheduling

· tracking labor costs and time reporting

· status reporting

· MS Project Professional - a project management tool that is used to develop the Work Breakdown Structure (WBS) and to track progress. Major tasks in the WBS should align with the project tasks in Daptiv.

The IED Delivery Center Daptiv Training Materials and References SharePoint folder provides Daptiv training documents, FAQs, and guidance.

Project Workspaces and Project Plans Using both a project workspace and project plan is key to establishing appropriate management, governance, tracking, reporting, and documentation for a project. The project workspace and project plan should be aligned but each has a different purpose.

· A project workspace is created in Daptiv when a project is approved through the BUS001 process. It is the responsibility of the Project Manager to manage resources, members, and tasks in the project workspace. The Project Manager must manage the member list, create resource plans, and assign resources to tasks for time tracking. Project progress and labor costs are derived from resource plans and tasks in the project workspace.

· Project Plans are used to develop the Work Breakdown Structure (WBS). It is the responsibility of the Project Manager to set up the project WBS/schedule in MS Project Professional and ensure that the WBS aligns with time-tracking tasks in Daptiv.

IT Project Governance As shown in Figure 1 at right, three basic entities govern IT projects.

· Project Governance Committee (PGC) is responsible for providing high-level guidance, change management approval, and resolution of issues that cannot be resolved by the PEMT.

· Project Execution Management Team (PEMT) provides consistent day-to-day project management.

· Project Execution Team (PET) carries out the project tasks.

Figure 1: Project Governance Overview Diagram

The roles and responsibilities of these distinct groups are further defined in the Standard IT Project Governance which is available on the IED DC IT PMO SharePoint Site: pagov.sharepoint.com.

Project Documentation Use of SharePoint – a collaborative software tool in use by the IED DC - supports project management by providing a means to store and share documents. All project documentation, especially documents referenced in this handbook should be retained on a project’s SharePoint site. It is recommended to have a project SharePoint site created at a project’s inception. SharePoint sites are created using a standard template. Further information on how to request a new SharePoint site is detailed in the SharePoint Web Collaboration Site Setup section of this document.

The IT Portfolio Development and Delivery Process The IED DC follows a four-step process to develop and deliver IT projects. Projects are selected and prepared for execution in the first three steps of the process. In the fourth step, the project is executed. A Project Manager participates in Project Initiation and is responsible for Project Execution. The IED High-Level Process Map shows each step from the identification of an IT need to the Executive Office approval of a project, to the completion of the project. Each Project Manager should be familiar with the complete process, including activities that take place before their involvement begins.

· IT Portfolio Development - the IT Project Portfolio is defined. IT needs are collected from all business units and are reviewed for impact on strategic objectives and other projects. Factors such as economies of scale, technology platform, requirements, complexity, cost, and resource needs are considered when evaluating and ranking new project requests. The requests are either accepted for inclusion in the portfolio or rejected.

· Commonwealth Approval Process – The Briefing on IT Approvals explains the OA/OIT approval process. Proposals for projects requiring OA/OIT approval are completed using the BUS001 Business Proposal Template. Refer to ITP-BUS001 for further details on the BUS001 policy. Note that as part of BUS001 the Project Manager may be requested to facilitate the development of the Business Project Estimate (BPE).

Further approvals include the following:

· IT Procurement Approval - must go through the BUS002 process if it meets certain criteria. See the ITP-BUS002 IT Investment Review Process for details. Other materials are found in the IED IT Portal.

· IT Investment Approval (TIPR) - New IT Pilot requests must follow an approval process, as well. For additional information, refer to the New Technology Pilot Program and Product Demonstrations.

· Project Definition – Once a project is approved for inclusion in the portfolio, each project that requires Office of Administration (OA)/Office of Information Technology (OIT) approval is submitted for their review and approval. Approved projects are then scheduled, and business units are informed of the approved project.

· Project Initiation - the project team is formed, and a draft project charter and project plan are developed.

· Project Execution - the project plan is further refined. Project requirements and potential IT solutions are defined, procurement of products and services are initiated as appropriate, the project is executed (monitored, managed, and controlled), reviewed, and closed.

This IT Portfolio Development and Delivery Process helps the IED DC ensure that each IT project is part of a strategic investment designed to enhance IED DC services. The diagram below graphically represents the process.

Figure 2: Overview of IT Project Development to Delivery Process NOTE: The IED DC IT Project Development and Delivery Process document further defines the above diagram as well as the make-up and responsibilities of the operational teams. The Portfolio Project Development Process diagram details the flow of the IT Portfolio Process and Project Prioritization.

NOTE: The Project Manager is typically not involved in Project Definition and is assigned to a project in the Project Initiation step.

Once a Project has progressed through IT PORTFOLIO DEVELOPMENT and PROJECT DEFINITION the project is passed to the Project Management Office for PROJECT INITIATION and PROJECT EXECUTION.

The next two Sections will describe the sub-processes and related activities for PROJECT INITIATION and PROJECT EXECUTION.

Section 2 – Project Initiation

2.1 Activities

Begin the following activities for Project Initiation.

Project Governance Document The Project Governance Document provides an overview of the project’s governance structure, defines the roles and responsibilities of the various governance teams, and lists individuals assigned to each team.

Related Documents/ Templates

Project Governance Document

Project Charter The Project Charter describes the project’s purpose, goals, objectives, and scope. Signed by the proper authorities, it serves as authorization for the project. Typically, this is drafted during Project Initiation and reviewed/updated as a part of Detailed Project Planning in Project Execution. This ensures that the appropriate detail is present and that all goals, objectives, and deliverables are still valid.

Related Documents/Templates

Project Charter Template

Project Start-up Checklist The Project Start-up Checklist serves as a step-by-step guide to our approach to managing projects. In the Project Initiation section, the Project Manager needs to review each item. These are either tasks that that are required to be started before Project Execution, or processes and approvals that must begin immediately. The processes and approvals may not be required for each project, but the Project Manager should review each so that process and approval may begin as soon as possible.

Refer to the Project Start-up Checklist for an explanation of each step, and links to relevant questionnaires, forms, or templates. The checklist is comprehensive and shows additional items that are not mentioned in this handbook.

Select Project Management Methodology Each Project Management Methodology has its pros and cons. The selection of the appropriate methodology is made depending on a variety of factors. Thoughtful consideration of the needs of the business, project timeframes, technologies, and other factors should go into the decision.

· Reduces risk of changing requirements

· The longer the iteration, the greater the risk

· Scope of each iteration is fixed, so schedule delays may result

· Breaks the project down into iterations or phases.

· Each iteration has its own lifecycle

· Easier to adapt to changes in requirements

· Customer is engaged throughout the entire project

· Builds strong teams

· Agile requires a significant culture shift

· Agile does not always conform to traditional large organizational performance metrics; effort estimations can be difficult

· Requires both the business/user community to be involved consistently throughout the project

· Developments teams must shift to daily reviews of work/progress

Please see APPENDIX B – IED DC IT Project Management Methodologies.

Section 3 – Project Execution

3.1 Project Execution Tasks

The following tasks comprise the project execution step in the IT Development and Delivery process.

Detailed Project Planning Detailed Project Planning refines and expands the draft plans developed in Project Initiation. It should be noted that the beginning of Project Execution may overlap with the completion of Project Initiation, so strong communication is important during this transition period. During Detailed Project Planning, Project Managers check off and complete all items that apply from the Project Start-up Checklist. Not all activities may be necessary for each project, but each should be considered to ensure that no critical activities are missed. Standard tasks for detailed project planning that usually occur for all projects are as follows:

· Draft Project Charter

· Draft Project Governance Document

· Set up members, create resource plan, and add resource task assignments in the Project Workspace in Daptiv

· Draft WBS

· Set up SharePoint Web Collaboration Site

· Verify that the Risk, Action Item, Issue, and Decision Logs are set up on the SharePoint Site.

· Conduct the PEMT Kickoff

· Review Draft Charter

· Conduct a Risk Analysis with PEMT/PET

· Develop Project Management Plan(s)

· Review the Project Charter, Project Management Plan, and Draft Project Plan/Schedule with PEMT

· Update the Charter, Project Management Plan(s), and Baseline the Project Plan/Schedule

· Update the resource plan and resource task assignments in the Project Workspace in Daptiv

· Obtain PEMT Approval for Charter and Plans

· Conduct the PGC Kickoff

· Obtain PGC Approval for Charter and Plans

Monitoring and Control

· Manage Project Change (Schedule, Cost, and Scope)

· Manage Daptiv workspace plans and review actuals

· Manage Project Schedule

· Manage Contractual Obligations

· Manage Deliverable Tracking Log/Deliverable Sign Off

· Manage Risks, Action Items, Issues, and Decisions

· Monitor Ongoing Lessons Learned

· Manage Communications

· Manage Project Change

· Manage Quality

· Manage Procurement Process

· Report Project Status

· Manage Approval of Project Deliverables

After Action Review

· Conduct Questionnaire

· Conduct AAR Meeting

· Update Lessons Learned Log

Project Closure

· Complete Project Closure Documents

· Complete Project Closure Tasks

Related Documents/Templates

Project Management Start-Up Checklist

3.2 Project Setup Tasks

The Project Manager is responsible for the setup of the Daptiv Workspace and requesting the setup of the project SharePoint site. Risk, Action Item, Issue, and Decision Logs are created as part of the project SharePoint site setup.

Daptiv Workspace Setup The Daptiv project workspace is created at the beginning of the project approval process. Once the project is approved and officially added to the Portfolio, the Project Manager adds members, creates the initial resource plan, and assigns members to project tasks for project time tracking. Initial labor estimates are derived from the resource plan and thus require thoughtful planning. Estimates are tracked and financial impacts greater than 20% can require a change request.

When the Project Manager begins to set up the Project Plan/Work Breakdown Structure (WBS) they will need to make sure that the WBS aligns with the time tracking tasks you set up in Daptiv (see the Project Plan/Work Breakdown Structure (WBS) section in this document for details).

Related Documents/ Templates

PM Weekly Checklist

SharePoint Web Collaboration Site Setup You can request a SharePoint Level 1 site, which includes only those functionalities that can be provided without any custom coding. Features of a SharePoint Level 1 site include:

· Accessibility by both internal (CWOPA) and external users

· Document versioning

· Standard SharePoint communication features including discussion boards, calendars, and announcements

· Standard SharePoint search features including tagging and metadata

· Self-managed security and permissions

· A standard SharePoint template structure, with limited end-user customizations

· Standard SharePoint reports

· Standard Workflow templates, with limited end-user customizations Because these sites include only out-of-the-box functionality and are end-user managed, they can be created quickly. A SharePoint Level 1 site will be provisioned for you within five business days.

All PMO Project SharePoint sites will be accessed through the Projects page of the PennDOT Enterprise SharePoint portal. Each PMO Project SharePoint is set up by the SharePoint team with a standard folder structure. For assistance with setting up a SharePoint site, please contact the PMO Administrator.

Related Documents/ Templates

Requesting and Setting Up a SharePoint Web Collaboration Site PMO SharePoint Site Provisioning Template New Site Details Template SharePoint Standard IT Document Management Folder Structure

Setting up the Risk, Action Item, Issue, and Decision Logs The Risk, Action Item, Issue, and Decision Logs serve as four individual SharePoint lists (each accessed through a navigation link under the RAID log heading) to continually monitor project progress. All four logs listed below are to be regularly reviewed by the PEMT.

Risks Project Risks should be documented within the Risk log, regularly reviewed by the PEMT, and resolved promptly. The Project Manager should monitor and watch for risk triggers that indicate a risk may be realized and become an issue. Changes to the risk likelihood or a negative impact on the project will result in the risk score or risk severity being adjusted. Critical Risks that cannot be resolved by the PEMT must be escalated to the Project Governance Committee promptly.

Action Items Action Items should be documented within the Action Items log, regularly reviewed by the PEMT, and closed in due course.

Issues Project issues should be documented within the Issues log, be regularly reviewed by the PEMT, and resolved within a proper time. Critical Issues that cannot be resolved by the PEMT must be escalated to the Project Governance Committee promptly.

Decisions Major Project Decisions should be documented within the Decisions log. Documenting the decisions helps to keep them visible to the entire team and serves as a reference when past decisions are questioned.

Related Documents

Action Item, Decision, Issue, and Risk Logs Description

Action Item, Decision, Issue, and Risk Logs Instructions

Standard IT Project Governance

Project Execution Management Team Kick-Off One of the early steps in Project Execution is to hold a kick-off meeting with the Project Execution Management Team to ensure all members are engaged in finalizing the Project Charter.

· Aware of the project scope, the deliverables, project schedule, progress reporting requirements, and individual roles and responsibilities. To ensure these and other items are discussed and understood, the Project Manager should use the Project Execution Management Team Kick-Off Checklist to prepare for and conduct the PEMT kick-off meeting.

Related Documents

PEMT Kickoff Checklist

Project Governance Committee Kick-Off After the Project Charter is completed and approved by the PEMT, a kick-off meeting is scheduled with the Project Governance Committee (PGC). This step in project execution ensures that the PGC is aware of the project approach, current and future activities, and schedule.

· The Project Manager should use the PGC Kickoff Checklist to prepare for and conduct the PGC kick-off meeting.

Related Documents

PGC Kickoff Checklist

Project Plan/Work Breakdown Structure (WBS) The Project Plan /Work Breakdown Structure (WBS) defines the tasks, their sequence, and their schedule. The first step in detailed project planning is to choose an SDLC and develop a WBS for the project. The Software Development Lifecycle (SDLC) is a strategy and logical process used to develop an information system. This usually includes:

· Initiation

· System Concept Development

· Planning

· Requirements Analysis

· Design

· Development

· Integration and Testing

· Implementation

· Operations and Maintenance These steps, however, can be arranged in other logical ways to form many other types of SDLCs. IED DC IT has moved to the utilization of Iterative and Agile methodologies. The objective is to select and use an SDLC that best suits the project, its deliverables, the estimated schedule, etc.

During the development of the WBS, the PM must consider the various processes, tasks, and duration. Early in the development, make sure to check items in the Project Startup Checklist and add necessary activities to the WBS to provide allowances in the schedule. Refer to the Project Startup Checklist for guidance.

In developing the WBS, the PM must consider the inputs of estimates and actual work between Daptiv and the Project Plan/WBS and their associated connections. The task list in Daptiv is pre-loaded with tasks that correspond to a value in the Daptiv Project Codes Cheat Sheet document. PMs can insert summary tasks from the Project Plan/WBS in the Daptiv task list as needed.

Project Management Plan(s) With input from the project team, the PM develops a comprehensive Project Management Plan. This template includes sections that cover a variety of common project management plans including:

· Communication Plan

· Configuration Management Plan

· Requirements Management Plan

· Quality Management Plan

· Document Management Plan

· Procurement Management Plan

· Stakeholder Management Plan

· Organizational Readiness

NOTE: It is the responsibility of the Project Manager to assess the unique needs of the project. If in their judgment the project management plan template does not adequately address communication, requirements, quality, etc., the PM may utilize pre-built plan templates to capture the required additional detail. The templates are available on the PMO SharePoint Site or can be accessed through the links provided in the descriptions below.

Project Management Plan This document defines how the project will be managed and combines abbreviated versions of full-size plan templates (i.e., communication plan, risk plan, quality plan, etc.).

Related Documents/ Templates

Project Management Plan

Communication Plan A communication plan describes how all internal and external communications will be handled, and provides details for disseminating information on project goals, progress, and outcomes. The communications plan should answer these questions:

· What project information will be communicated?

· Who will receive this information?

· When will this communication take place?

· What medium will be used for this communication?

· How often will this communication take place?

Related Documents/ Templates

Communication Plan Template

Configuration Management Plan Configuration Management is a process by which changes to software code are controlled during the various phases of the project. The Configuration Management Plan template is used to define the process and tools that will be used for this purpose.

Related Documents/ Templates

Configuration Management Plan

Requirements Management Plan The Requirements Documentation template is used by IED Business Analysts to document all requirements for a project. All requirements must be traced back to a business goal and/or objective as identified in the final approved Project Charter.

The primary SDLC tool used for gathering requirements is Azure DevOps. Please contact the SDLC team for further information and access.

Related Documents/ Templates

Requirements Management Plan Template

SDLC Contacts:

Gaurav Vig c-gvig@state.pa.us Hans Wertz hawertz@state.pa.us

Quality Management Plan Quality management involves activities determining specific quality objectives and responsibilities and then implementing them through quality planning, quality assurance, and quality control processes. The primary quality management objective for all projects is to ensure the project will meet or exceed customer requirements and expectations.

· The Quality Management Plan (QMP) addresses two key areas of quality: Quality Assurance and Quality Control. Quality Assurance (QA) is the application of planned, systematic quality activities to ensure that the project employs all key PM processes and meets project requirements. The level of quality assurance management earmarked for a given project is in proportion to the scope and visibility of the project.

· Quality Control is the application of processes to ensure the deliverables of the project meet or exceed the requirements. The QMP defines the Quality Control steps that will be taken during the project to ensure each deliverable meets or exceeds the requirements outlined in the Charter and Requirements documentation.

Related Documents/ Templates

Quality Management Plan

Document Management Plan Document Management is an important part of managing, monitoring, and evaluating project performance and results. The purpose of the document management plan is to control how project documentation is stored, retrieved, and archived. IED DC uses SharePoint sites for this purpose. The PMO is responsible for setting up the SharePoint site at the request of the PM.

The SharePoint site, its folder and sub-folder structure, the file naming convention, document templates, version control, and backup and retention policy should be incorporated into the plan. The Document Management Standard provides a methodology for the naming and filing of project documents. Documents must be stored where they are accessible to all team members, and they must be handled and named consistently. It is expected that most project documents will exist in an electronic format; however, similar rigor is required for ensuring proper management of hardcopy documents that are part of a project’s document library. For guidance, please see the Project Document Management Standard.

Related Documents/ Templates

Document Management Standard

Procurement Management Plan The procurement management plan identifies the items that must be purchased to carry out the project and the best procurement vehicle for those items. The Project Manager should work with the project team and involve the project Contract Manager as needed to construct the plan.

Related Documents/ Templates

Procurement Management Plan

Stakeholder Management Plan Some projects have many stakeholders and the communication to those stakeholders may be complex. In such cases, it is best to conduct a detailed stakeholder analysis to ensure all stakeholders are identified and their needs concerning project communication are captured and carried out. The Stakeholder Management Plan Log should be used to list the stakeholders, identify, and document their needs, and capture (log) each communication to ensure stakeholder needs are being met. Note: Smaller projects or projects with limited Stakeholder communication can utilize the Communication Plan for this purpose.

Related Documents/ Templates

Stakeholder Management Plan

Communication Plan Template

Organizational Readiness Plan Organizational Readiness is the ability of the organization to fulfill obligations regarding IT projects by providing information technology, personnel, resources, information, or knowledge in due course to make the project a success. In addition to items provided, organizational readiness includes the organization’s ability to receive, accept and use new information, tools, capability, software, and process created by the project.

Related Documents/ Templates

Organizational Readiness Template

Risk Analysis Risk management is the systematic, proactive process of identifying, analyzing, and responding to project risk. To do this, the project manager must work with the PEMT and PET to identify and document risks, weigh their potential impact, identify risk triggers, and develop mitigation strategies. The Risk, Action Item, Issue, and Decision Logs guide the identification/assessment process, as well as a single location where risks can be logged and monitored. Any risk identified in the IT Portfolio Development Process should be incorporated into the Risk Log.

Project Monitoring and Control Tasks Project Monitoring and Control is a recurring series of activities to ensure project tasks are completed on time, on budget, and within the scope defined in the Project Charter. In this step, the Project Execution Management Team monitors and evaluates task progress through communication with the Project Execution Team.

Related Documents/ Templates

PM Weekly Checklist

Manage Project Plan (Schedule, Cost, and Scope) Tracking project schedule, cost and scope is vital to controlling the project and reaching the goals and objectives within the schedule and budget allowed.

· The PM should manage to the plan by meeting regularly with the Project Execution Team (PET) to ascertain the project status.

· The PM should monitor time entry for each project member in Daptiv. Regular monitoring is required since actual costs are tracked across the IT Portfolio. The PM should review utilization – comparing member time entry and Actual Work vs. Work usage. By comparing the actual time (time entered via Daptiv timesheets) to complete each task against the baseline estimates, the PM can identify variations and take action(s) to correct schedule or budget variances. Corrective actions may include:

· working with PET resources to understand their issues,

· find and implement solutions to issues, and

· escalate issues through the governance process as necessary to maintain project baseline projections

Manage Contractual Obligations The purpose of contract management is to monitor, manage and enforce all contractual obligations. If the project includes a contract, a Contract Manager (CM) is assigned. The PM should meet regularly with the CM to ensure that the provider of goods and services satisfies all contractual obligations within schedule, within budget, and in a quality manner, including SLAs. It is the PM’s responsibility to keep the CM informed of all PEMT and Governance Committee decisions that may affect the contract.

Related Documents

Request for Proposal (RFP)

Vendor Contract/SOW

Completed and Approved Project Charter

Other Contractual documents

Deliverable Tracking Log/ Deliverable Sign Off The Project Charter defines who is responsible for the review and approval of Deliverables. The purpose of the Deliverable Tracking Log is to document when the Deliverables were presented to the group responsible for the review, and when formal acceptance of the Deliverable (sign-off) was received. The sign-off is most often obtained through an email voting procedure. This procedure, a feature of MS Outlook, permits the formal documentation of the approval or rejection of the deliverable. For more information on this process please see the link below.

Related Documents

Completed and Approved Project Charter

Deliverable Tracking Log

Email Voting Approval Template

Manage Risks, Action Items, Issues, and Decisions The Risk, Action Item, Issue, and Decision Logs are lists to capture project information throughout the entire project lifecycle. PMs should update the Risk, Action Item, Issue and Decisions logs a minimum of once per week and post it to the SharePoint collaboration site for team access and use.

Monitor Ongoing Lessons Learned As various issues arise and are resolved throughout the project, they may become valuable “lessons learned” for future projects. These should be captured in the PM’s Lessons Learned Log. The log is a spreadsheet with multiple tabs for various project phases including Planning, Execution, Monitoring, and Control and Close. These lessons must be captured for reuse during the project. At project close, the log should be reviewed to ensure there are no duplicates or items that are specific only to that project. Lessons that apply to any project should be transposed onto the PMO’s Master Lessons Learned Log. This provides a valuable resource for future projects.

Related Documents

PM's Lessons Learned Log

PM's Master Lessons Learned Log

Manage Communications Regular communication ensures that project team members and stakeholders stay involved and provide valuable assistance in meeting project goals and objectives. Because of the crucial role of timely, consistent communications throughout the project, Project Managers should fully execute the Communications Management Plan and routinely assess its effectiveness.

Related Documents

Communication Plan Template.doc

Manage Project Change As a project progresses, the PEMT may develop a better understanding of what is needed to produce the desired results. This increased understanding can manifest itself as changes to the project activities, and/or changes to the project's deliverables. A change management process is necessary to ensure a consistent approach to preparing, escalating, and approving change requests and to assure effective control of the project scope, budget, and overall schedule. The change management process includes:

Initiate Change - Requests for changes to the project's scope or specific deliverables may come from many different sources: management, business partners, users, technical resources, or other team members. Each request should be logged using the Change Request Template.

Conduct Impact Analysis – The Change Request Template provides a place for the documentation of change impacts. They may include impacts on the cost, schedule, resources, requirements, goals/objectives, deliverables, etc. In addition, the impact analysis should include any additional expertise that may be required, organizational changes, or impacts to the project benefits. The findings of the Impact Analysis should be summarized for Governance Committee Review.

Governance Committee Review – The findings of the Impact analysis should be presented to the Governance Committee in a succinct and focused manner (e.g., presentation, handout). In addition, a schedule for the changes should be defined, the process by which the change will be carried out, and a clear recommendation or options for action. Bear in mind that the governance committee will be reviewing and considering both the impact of the change as well as the process for carrying out the change.

Approval/Rejection – If the Governance Committee approves the change, the PM updates the Change Log with the agreed action, and the decision is noted in the Governance Committee meeting minutes. The PM follows the Approval -Implement Change steps below. If the change request is rejected, the PM notes the decision in the Governance Committee meeting minutes and follows the Rejection-Alter/No Change steps below.

Approval - Implement Change

1. Communicate the change(s) and the Governance Committee decision to all stakeholders per the Communication plan.

2. Make appropriate schedule and other project plan adjustments and communicate these to affected team members.

3. Re-baseline the Project Plan

4. Make any required changes to all affected project documents. If the document is a controlled document (e.g., Project Charter), draft the changes and initiate the review and approval process with all appropriate individuals.

5. Communicate the change(s) and the Governance Committee decision to all stakeholders per the Communication plan.

Rejection - Alter/No Change

1. Provide additional information about the change request as requested by PGC or,

2. Alter/revise the change request for resubmission and consideration by the PGC or,

3. Work within the baseline parameters with no change.

Major Change Requests must go through the BUS001 process. Change Requests considered major include:

· Scope change

· New/different technology needed

· Financial impact 20% more

· Schedule impact 20% more

· Requires new procurement

See documents in the IED IT Portal for further information.

Related Documents

Standard IT Project Governance

Project Change Request Template

Project Change Request Log Template.xls

Other Project Plan Documents as appropriate including the WBS

Manage Quality The Project Manager manages the Quality of a project by ensuring that the processes, interim review, and final reviews defined in the Quality Management Plan are carried out.

Related Documents

Quality Management Plan

Corrective Action Log

Manage Procurement Process The project manager is responsible for tracking items that must be procured for the project. Items must be procured on or under budget and on time. To assure success the procurement task should be built into a project schedule. Any procurement that is critical to the project's success should also be represented in the Risk log. Any delays in procurement should be entered in the project issue log.

Related Documents/ Templates

Procurement Management Plan

Report Project Status Status Reporting is an essential part of effective project management. It ensures a continuous dialogue that is vital to the project’s success. All projects, regardless of the complexity Level, are subject to executive reporting via Project Profiles which are maintained and updated by the PMO. In addition, the PM must report project status using the Project Status Report Templates in accordance with the Project Governance and Communication Plans.

Status reports are reviewed at PEMT meetings typically held weekly, and at Project Governance Committee meetings held on the schedule defined in the Project Charter.

Related Documents/Templates

Weekly Status Report Template

Project Governance Committee Status Report

Project Governance Committee Meeting Agenda Template

PEMT Meeting Agenda Template

Approving Project Deliverables Project Deliverables must be reviewed and approved to ensure they meet the expectations and quality as defined in the Project Charter. Reviewers should be tasked with that responsibility and allotted time for that activity within the Project plan. Final approval shall be granted by the approving body as defined in the Project Charter (e.g., PEMT, PGC).

Related Documents/Templates

Approval Email Template

After Action Review (AAR) As a part of Project Closure, an After Action Review (AAR) is conducted to capture lessons learned from the project and help Project Managers and project execution teams perform better and reduce issues on future projects.

During the AAR, the project team reviews the CBA and determines if further assessment and/or reporting is needed.

Related Documents/Templates

AAR Questionnaire

AAR Process

Lessons Learned Log

AAR Meeting Presentation

Project Closure Once all the project deliverables of a completed project have been completed and accepted, and all contractual obligations have been met, closure tasks may begin. A project closure checklist is used to ensure that all deliverables were completed and approved, that all appropriate documentation has been completed and posted to the SharePoint Site, and that the Project Plan/WBS is properly closed in the Project Management Tool. Complete project closeout activities in Daptiv, making sure to close out tasks, and check that all project time has been submitted and approved. Work with the Project Planning and Performance division to confirm all closeout activities are completed both in Daptiv and in the IT Portfolio. Please reference the Project Closure template for instructions and a checklist.

Related Documents/Templates

Project Closure

Project Closeout Template

Project Management Checklist - Closure of Project Plan

Appendices

APPENDIX A

Acronym and Abbreviation /Glossary

Activity A logical grouping of project tasks. (See Task and Phase definitions)

Actuals The cost or effort (e.g., hours) incurred in the performance of tasks. Also, the date’s tasks have been started or completed and the date’s milestones have been reached.

Action Item An action item is any task identified through discussion or meeting that moves the project forward in some way. Action items are documented in the Action Item Log where they are assigned to an individual or group with a unique AI number and estimated due date.

After Action Review (AAR) An activity to assess and evaluate the way a project was performed, to learn from the experience, and continuously improve project performance.

Agile The Agile methodology is a way to manage a project by breaking it up into several phases. It involves constant collaboration with stakeholders and continuous improvement at every stage. Once the work begins, teams cycle through a process of planning, executing, and evaluating. Continuous collaboration is vital, both with team members and project stakeholders.

Baseline A point of reference. The plan is used as the comparison point for project control reporting. There are three baselines in a project—schedule baseline, cost baseline, and product (scope) baseline. The combination of these is referred to as the performance measurement baseline.

Budget Planning App If a new project, change request, or new software must be purchased, the request needs to be entered in the Budget Planning Application. Typically, the IT Division Chief under whose purview the project falls completes this step.

BUS001

Process for business proposals, information technology project approval, and the assignment of resources and responsibilities to ensure agency IT projects align with the Commonwealth’s goals and objectives

BUS002

The policy and procedures for the Office of Administration, Office of Information Technology (OA/OIT) review and approval of Information Technology (IT) Investments

BUS004

The process and procedures for requesting and approving waivers to Information Technology Policies (ITPs) published by the Office of Administration (OA), Office for Information Technology (OIT).

Business Relationship Manager A business relationship manager (BRM) is the IT liaison for each department in an organization. A BRM understands all business processes and provides technology guidance to ensure maximum return on investment (ROI) for IT business strategy requirements. A key BRM role is reducing business and IT barriers.

Change Control The process of managing scope, schedule, and budget changes to the plan. See Scope Change Control.

Change Request A documented request for a change in scope or other aspects of the plan.

Charter (See Project Charter) Closing (See Project Closing)

Communication Plan The Communication plan defines the type and scope of project information that will be shared regularly throughout the project’s lifecycle. In addition, it defines the frequency and method of information delivery.

Constraint A restriction or limitation that influences the project plan. For example, a target date may be a constraint on scheduling. A schedule may be constrained by resource limitations.

Configuration Management Method for managing the software builds versions during the project lifecycle.

Contract Management Methods and processes for controlling and managing the project contract(s).

Controlling The process of monitoring, measuring, and reporting on…