APPENDIX S PROJECT MANAGEMENT TEMPLATES - PA System Requirements The detailed description of the business and system requirements describing the changes needed on screens, reports,

1

APPENDIX S

PROJECT MANAGEMENT TEMPLATES

1

Table of Contents Project Charter ............................................................................................................................... 2

Standard IT Project Governance ................................................................................................ 11

Project Management Plan .......................................................................................................... 27

Communication Plan .................................................................................................................. 36

Quality Management Plan .......................................................................................................... 45

Document Management Standard ............................................................................................. 54

Project Change Request .............................................................................................................. 68

2

Project Charter <Project Name Here>

Last Updated:

Version:

Prepared by:

Sponsoring Deputate:

<Project Name>

3

Date Version Description Author

<Project Name>

4

Table of Contents

1. Project Background and Description

2. Project Goals and Objectives

3. Project Scope

4. Deliverable(s) and Approval

5. Stage Gate Approvals

6. Schedule/Time Tracking/Governance

6.1 Schedule

6.2 Estimate to Complete (ETC)

6.3 Governance Committee Meeting Responsibility

7. Constraints

8. Expected Benefits

9. Project Success Criteria

10. Project Charter Approval

<Project Name>

5

1. Project Background and Description [This section should include a description of the background circumstances and events that have caused the need for the project to be conducted.]

2. Project Goals and Objectives [This section sets forth the ultimate outcome of the project in business terms. It is generally not quantifiable, time-dependent or suggestive of specific actions for its achievement. Objectives are specific ends, conditions or states that are steps toward attaining a goal. They should be achievable, measurable and time-specific. Number goals and objectives to associate them with dependent business, user and system requirements.

For example:

Goal #1 Reduce the impact of severe weather on our citizens

Objective 1.1 - Provide an information delivery system that allows users to receive information automatically in a useful format (alerts and reports)

Objective 1.2 - Integrate weather alerts with appropriate emergency preparedness plans and instructions.]

3. Project Scope [This is a brief statement of the preliminary project scope. The description can include those things which are out of scope to provide clarity to the scope of what will be done. For instance: This project will include a revision of the application code to bring about the following enhancements: Improved workflow, and improved reporting capability. The project will not address changes to the user interface.]

4. Deliverable(s) and Approval [Deliverables are the final work products of the Project. For example: A system requirements specification document, a finalized Data Structure, tested and approved code. This list is developed based on the Goals and objectives above as well as the project scope. Items below are standard deliverables that require approval.]

<Project Name>

6

No. Name Description Deliverable

Approval+

Completed by

1 Detailed Business and

System Requirements

The detailed description

of the business and

system requirements

describing the changes

needed on screens,

reports, and processes.

PEMT BA

2 Traceability Matrix

Document which will

trace all business

requirements and

system requirements to

an appropriate goal,

objective, and test script

which will be used

during system testing.

PEMT BA

3 Detailed Design

Document(s)

The design document

will include the

workflow, data

modeling, security,

business use cases and

screen shots necessary

for the system to

perform the required

functionality.

PEMT BBSS/BA

4 Project Plan and

Schedule

Detailed project

timeline and

implementation dates.

PEMT/PGC PM

<Project Name>

7


Approval+

Completed by

5 Test Management Plan The high-level

document explaining

the system testing

expectations, the

required environment,

the testing scenarios to

be tested, the actions

taken should a test fail,

and the method by

which errors are

classified. To include

Performance,

Regression, System and

UAT testing and

supporting

documentation needed.

PEMT BA

6 UAT Outcome Report The results of the

testing will be

documented and

summarized within a

final test report.

PEMT BA

7 Training Plan The plan that describes

how training will be

developed and delivered

to the users

PEMT HA

8 Data Migration Plan Plan for how the

current system’s data

will be effectively

migrated to the new

system and validated.

PEMT BBSS & HA

<Project Name>

8


Approval+

Completed by

9 Implementation Plan This document

describes the process,

tasks, and responsible

individuals associated to

pre-implementation,

implementation, and

post implementation

activities for rolling out

the system.

PEMT BBSS

10 IT Service Desk

Procedures

This document is a

standardized template

within PennDOT that

addresses the

procedures and

processes for handling

IT Issues and questions

regarding the

application.

PEMT BBSS

11 Transition Plan The documentation

necessary to turn-over

this project to the

Managed Maintenance

team and the

documents used by the

Help Desk for support

of the system.

PEMT BBSS

12 Decommission Plan Plan that outlines how

and when the current

OAD&J system will be

archived and

decommissioned.

PEMT BBSS & HA

13 Scope definition of

Stage 2

Revised Charter that

includes scope

definition of Stage 2

and future releases

PEMT/PGC BA

<Project Name>

9


Approval+

Completed by

14 Ball Park Estimate on

Level of Effort for Stage

2

Estimate for IT level of

effort and time frame

for completing stage 2

future releases.

PEMT/PGC BBSS

+ Project Governance Committee or Project Execution Management Team

5. Stage Gate Approvals [Based on the Final Project Plan and WBS, define the points at which the Project Governance Committee must review and provide approval before the project can continue.]

6. Schedule/Time Tracking/Governance 6.1 Schedule

<Sample Text: This project is expected to commence on <Date> and be completed before <Date> >

6.2 Estimate to Complete (ETC) PEMT members and other Key Project members are required to assist the PM in the establishment

of the estimated effort (hours) required to complete each of their assigned tasks and to enter their

time each week in MS Project Online in a timely manner.

6.3 Governance Committee Meeting Responsibility

<Sample Text: It is expected that all Project Governance Committee members and Project Execution Management Team members attend the Governance Committee meetings that are scheduled for this project. The meetings will be scheduled at the following project milestones listed below. In addition, emergency meetings may be scheduled at the request of any team member as needed.

Milestone #1 – Description Here



Note: It is suggested that each team member send a representative with decision making authority to any meeting that they are unable to personally attend due to schedule conflicts etc. >

(Some projects may require monthly meetings or only as needed meetings or the meetings may be part of an overall program PGC meeting. In this case, update the standard text above to clearly represent the expectations regarding PGC meetings.)

<Project Name>

10

7. Constraints [In this section describe any high level constraints that will affect the project. Is this a Federal Mandate? Is there a drop dead date for implementation? Must a particular technology be used?]

8. Expected Benefits [The benefits expected from successful completion of the project should be listed here. These are business outcomes. For example, benefits can include things like improved customer service, ability for citizens to conduct transactions on the web, faster turnaround of transactions, or access to information not previously available.]

9. Project Success Criteria [The criteria under which the project will be measured should be listed here. These should be measurable criteria. As an example: All deliverables included in the project scope were completed; Project completed on or under baseline schedule; Project completed on or under baseline budget.]

10. Project Charter Approval Approval of the Project Charter indicates an understanding of the purpose and scope of the

project and agreement with this document’s contents.

Charter Approvals will be collected via email approval. Approvers include:

<List Approvers Here – Should Include all voting members of the PEMT and PGC.>

<Project Name>

11

Standard IT Project

Governance

Version: 3.0

Last Modified: 1/31/13

Prepared by: PennDOT IT PMO

Standard IT Project Governance

12


12/2/08 1.0 Initial version PMO

12/19/08 1.1 Added Project Contract Manager to governance structure.

PMO

6/5/09 1.1 Added Business Review and Results office PMO

7/6/09 1.2 Removed references to BRRO activities outside of Execution phase.

PMO

7/29/09 1.3 Changes to reflect Level 1 requirements PMO

11/3/09 1.4 Update to ensure CIO is signs off on Project Charter. See page 4.

PMO

6/1/11 2.0 Update Versioning PMO

1/31/13 3.0 Removed Executive Committee PMO

Standard IT Project Governance

13

Table of Contents

Document Purpose

Standard IT Project Governance Structure Overview

The Project Governance Committee

The Project Execution Management Team (PEMT)

The Project Execution Team

Program Governance

Other Groups/Teams

Issue Management and Escalation

Project Change Management

Appendix A – Project Execution Management Team Role and Responsibility Matrix

14

Document Purpose This document defines the Standard Governance Structure for PennDOT’s Information

Technology (IT) projects in the Execution phase. Note: Variation to this standard governance

process is permitted, but it must be justified and approved by OIS Management.

Standard IT Project Governance Structure Overview

There are three groups that govern IT projects:

The Project Governance Committee is responsible for providing high level guidance and executive oversight;

The Project Execution Management Team provides consistent day-to-day management of the project tasks;

The Project Execution Team carries out the project tasks.

The roles and responsibilities of these distinct groups are further defined in subsequent sections of

this document.

Project Governance Committee

Project Execution Management Team

Project Execution Team

Issu

es/

Ch

ange

Re

qu

est

s

De

cisi

on

sCommunication

Communication

The Project Governance Committee The role of the Project Governance Committee is an important one - particularly in large and

complex projects. An IT project is a significant investment for the Department and it is the

responsibility of the Project Governance Committee to ensure that the goals and objectives of the

project are met and that resources are applied wisely. The individuals assigned to the Project

Governance Committee need to be dedicated to the project and have the authority and knowledge

15

to make important project decisions. The committee should be small enough to ensure effective

decision-making but large enough to ensure the right breadth of knowledge to make these decisions.

Project Governance Committee Roles and Responsibilities

The roles and responsibilities of the Project Governance Committee include:

Provide guidance and direction to project leads

Monitor and review (steer) the project.

Attend Project Governance Committee meetings.

Resolve project issues related to budget/scope/schedule/resources in a timely manner.

Review and approve/reject changes to budget/scope/schedule that come through the formal approval process.

Review and accept project deliverables (as needed).

Provide approval for a project to move from one phase to another.

Consult with colleagues when project decisions require knowledge outside of the Project Governance Committee members’ collective expertise.

Project Governance Committee Members The standard members of the Project Governance Committee (PGC) for each project are provided

below. These role assignments are made at the start of the project and reviewed whenever there is a

significant project event (such as the loss of a resource or a significant scope change).

Core Team Members:

Chair

IT Representative(s)

Business Area Representative (s)

Signature Authority The Chair, IT Representatives and Business Area Representatives typically have signature authority

for project deliverables. Other members will typically not have signature authority for deliverables.

Project Governance Committee Meetings

The meeting schedule for the PGC meetings will be determined at the start of the project. Project

Governance Committee meetings will be focused and concise. Unless there are significant issues, the

meetings will last 60 minutes or less.

The purpose of a regular Project Governance Committee meeting is to:

Review the current status of project as presented by the Project Execution Management Team.

Address and resolve issues that have been escalated to the Project Governance Committee

Review project change requests and approve or reject such requests.

16

Provide general guidance to project leads.

Recommend corrective action when needed.

The Project Governance Committee meeting will not be used for a design session or a detailed discussion of non-priority issues.

Project Governance Committee meetings will not be the vehicle for sharing project information with stakeholders. Stakeholder management and communication is outside of this structure.

Project Governance Committee Chairperson Responsibilities The PennDOT CIO (or person delegated this authority by the CIO) will serve as the chair of the

Project Governance Committee. The responsibilities of this position are:

Provide formal approval for the final project charter.

Chair regular meetings.

Convene emergency meetings as needed.

Provide formal approval of all project deliverables requiring Project Governance Committee approval.

Regular Attendees of Project Governance Committee Meetings

In addition to the committee members, the following individuals should attend Project Governance

Committee Meetings for each project:

Resource Role

Project Manager Facilitate meeting; provide status

Business Lead(s) Provide status

IT Lead(s) Provide status

Vendor Project Manager Prepare meeting documents; provide status

The Project Execution Management Team (PEMT) PEMT Roles and Responsibilities

The role of the PEMT is to:

Provide the day-to-day leadership for the project to ensure that project deliverables are completed on schedule, on budget and meet the business requirements.

Provide project status information to the Project Governance Committee.

Address and resolve day-to-day project issues

Escalate issues that cannot be resolved by PEMT to the Project Governance Committee with recommendations for resolution.

Prepare and escalate change requests to the Project Governance Committee.

17

Review and accept those project deliverables designated in the Project Charter as requiring PEMT approval.

Review and recommend for approval those project deliverables designated in the Project Charter as requiring Project Governance Committee approval.

PEMT Members The standard members of the PEMT for each project are provided below. These assignments are

made at the start of the project and are reviewed whenever there is a significant project event (such

as the loss of a resource or a significant scope change).

Core Team Members:

A brief description of the responsibilities for the core team members is provided below. Refer to

Appendix A for a detailed description of the standard Roles and Responsibilities for the Project

Manager, IT Lead, Business Lead and Vendor Project Manager.

Project Manager Responsible for the execution of the project plan and day to day management of the project

following the established Project Management Methodology.

Business Lead(s)

Responsible for ensuring business needs are met and business resources are included appropriately in the project.

This includes ensuring that project issues that require business resource input are resolved quickly and that any deliverables that need to be completed or reviewed by the business resources are completed per the project schedule.

IT Lead(s) Responsible for ensuring IT needs are met and IT resources are included appropriately in the

project.

This includes ensuring that project issues that require IT resource input are resolved quickly and that any deliverables that need to be completed or reviewed by the IT resources are completed per the project schedule.

Vendor Project Manager Responsible for ensuring that vendor contractual requirements are met and that project tasks

assigned to the vendor are completed on time and on budget.

Note: Refer to Appendix A for a detailed description of the standard Roles and Responsibilities for

the Project Manager, PMO Lead, IT Lead, and Business Lead.

18

Core Team Member Reporting Relationship Structure:

Project

Management

Division Manager

IT Project

Manager

IT Lead

Business Lead

Project

Management

Division Manager

IT Project

Manager

IT Lead

Business Lead

Vendor Project

Manager

Business

Resources

IT Resources

Vendor Resources

Business

Resources

IT Resources

Project/Program Governance Committee

Project/Program Governance Committee

IT Projects Delivered with Internal Resources IT Projects Delivered with Vendor Resources

Indicates direct reporting relationship

Indicates indirect reporting relationship

Supportive Team Members

Based on the project composition and need, the following team members may be included into

PEMT.

Managed Maintenance Team Lead If a project has significant tasks to be completed by the Managed Maintenance team, a lead from this

team is assigned to the PEMT. This person is responsible for managing the tasks of the Managed

Maintenance team and providing regular status updates to the PEMT.

FHWA Representative

Some IT projects require Federal Highway Administration (FHWA) involvement. At the discretion of the PennDOT IT leadership, an FHWA representative may be assigned to a project.

PEMT Signature Authority The core team members (PM, IT Lead and Business Lead) typically have signature authority for

project deliverables (unless they are not Department employees). Other members will typically not

have signature authority for deliverables.

19

PEMT Meetings

The Project Execution Management Team will meet on a regular basis (details and meeting logistics will be provided in the project Communication Plan). The purpose of the regular Project Execution Management Team meeting is to:

Review project status to ensure that project tasks are progressing in accordance with the approved project schedule, budget, and scope.

Address issues raised by Project Execution Team (PET) members

Recommend resolution options for issues that cannot be addressed at the PEMT level and escalate those issues and recommendations to the Project Governance Committee.

Prepare and escalate change requests to the Project Governance Committee.

Address questions/corrective action received from Project Governance Committee.

The Project Execution Team Project Execution Team Responsibilities

The Project Execution Team includes IT, business area, and consultant resources. The role of the Project Execution Team is to:

Complete the project deliverables

Provide status to the Project Execution Management Team

Escalate issues and change requests to the Project Execution Management Team

Project Execution Team (PET) Members

Some typical members of the Project Execution Team for each project are provided below. However, the make-up of this team will vary based on the project needs and may change through the life of the project.

Project Contract Manager

The responsibilities of this resource are to provide and track all contract and budget related information needed for the execution phase of the project.

Business Analyst

One or more business analysts may be assigned to a PET for collecting and maintaining requirements. This resource(s) may also participate in the testing phase of the project.

Technical Resource

One or more technical resources may be assigned to a PET and assigned specific tasks needed to complete the project. Typically the IT lead will provide oversight to these resources.

20

Technical Lead

BIO and/or BBSS Management may assign a technical lead for PET technical resources to support the IT Lead in providing oversight to those resources.

Subject Matter Expert (SME)

One or more resources may be assigned to a PET and assigned to tasks that require specific expertise needed to complete the project.

PET Signature Authority

The PET members do not typically have signature authority for project deliverables

.

PET Meeting Attendance

PET members may be regular or ad hoc attendees at the various project meetings.

Program Governance Projects that are part of an established program and that have a defined Governance Structure (such as the Intelligent Transportation Program) will follow the Governance Structure defined for that program. However, all projects, even those considered part of the program, will have a PEMT and PET defined at the project level. A project-specific PGC may not always be required as the responsibilities of these project teams may be absorbed within the program’s governance structure.

Other Groups/Teams Other groups/ teams can be established at any level of the governance structure. For example, (1) the Project Governance Committee could request quarterly Stakeholder meetings to provide project status information to key stakeholders or (2) the Project Execution Management Team could convene a budget management team that meets weekly to review the project budget or (3) the Project Execution Team could create smaller teams such as a database team to address the completion of specific project deliverables.

Issue Management and Escalation The Project Execution Management Team is responsible for the management of risks and issues during project execution.

Issue Escalation

Over their lifecycle, all projects experience issues. Project success is based on the effective resolution of each issue. The following issue escalation procedure shall be followed:

21

All issues must be reported to the project manager as soon as they are discovered.

All issues must be documented in the project issues log and reviewed/addressed in a timely manner, as dictated by the severity level.

Any issue that cannot be resolved by the Project Execution Team shall be escalated to the Project Execution Management Team. All members of that team should be made aware of the issue at the same time so that they can collectively address and resolve the issue.

Any issue that cannot be resolved by the Project Execution Management Team shall be escalated to the Project Governance Committee.

22

Project Change Management Change control is an organized approach to tracking and monitoring changes in a project. It is supported by a formal process for making changes to the project's original scope that drives the project goals and deliverables. An overview of the standard project change management process is provided below. The Requestor is the person who initiates the change request. The Assessor is the person assigned to determine the overall impact of the change request.

Change Management Process

Go

ve

rna

nce

Co

mm

itte

e o

r

PE

MT

Asse

sso

rP

roje

ct

Ma

na

ge

r R

eq

ue

sto

r

Complete Change

Request Form

Log Request,

assign for

assessment

Asses impact and

complete

assessment

template

Review change

and its impactApproved?

Adjust Project

Plans (Re-Basline)

and

Documentation as

required

Communicate

changes to

Stakeholders and

Teams

Communicate

rejection to

Stakeholders and

Teams

Yes

No

23

Appendix A - Project Execution Management Team Role and Responsibility Matrix

Project Manager IT Lead (s) Business Lead Vendor Project Manager

Responsible for the

execution of the PM

methodology and project

plan and day to day

management of the project.

Responsible for ensuring IT needs

are met and IT resources are

included appropriately in the

project.

This includes ensuring that project issues that require IT resource input are resolved quickly and that any deliverables that need to be completed or reviewed by the IT resources are completed per the project schedule.

Responsible for ensuring

business needs are met and

business resources are included

appropriately in the project.

This includes ensuring that project issues that require business resource input are resolved quickly and that any deliverables that need to be completed or reviewed by the business resources are completed per the project schedule.

Responsible for ensuring that

vendor contractual requirements

are met and that project tasks

assigned to the vendor are

completed on time and on budget.

PM and SDLC

Methodology

Ensure PennDOT PM

Methodology is being

applied and comprehensive

Governance Plan is created

and adhered to. Provide

guidance on PM standards

and templates.

Ensure PennDOT's IT standards

and SDLC are applied. Provide

guidance on templates and

standards for technical

documentation and IT

development.

Adhere to PennDOT's PM and

development standards /

methodology and standards and

templates for PM Artifacts and

Project Deliverables.

Resource Planning Assist IT and Business Leads in monitoring IT and Business team member project activities.

Ensure project team roles

are assigned and clearly

defined.

Ensure all project resources

are reflected in the project

plan.

Ensure appropriate IT staff is assigned to the project at the appropriate time.

Ensure appropriate business

experts are assigned to the

project at the appropriate

times.

Ensure appropriate consultant

resources are assigned to the

project at the appropriate times.

24


Project

Communication

Develop, maintain and

execute the Communication

Plan.

Create meeting minutes and

other project

communications as

described in the project

Communication Plan.

Review and provide

comment on all project

communications.

Note: If a vendor PM has

responsibility for creating

the Communication Plan,

the Project Manager is

responsible for ensuring it

meets PennDOT’s needs and

is adhered to throughout

the project.

Ensure IT resources are included

appropriately in the

Communication Plan.

Create meeting minutes and other

project communications as


Communication Plan. Review and

provide comment on all project

communications.

Ensure Business resources are

included appropriately in the

Communication Plan.

Create meeting minutes and

other project communications

as described in the project

Communication Plan. Review

and provide comment on all

project communications.

Develop, maintain and execute the

Communication Plan.

Create meeting minutes and other

project communications as


Communication Plan. Review and

provide comment on all project

communications.

Baseline Project

Plan

Owner of the work plan in

the PM scheduling tool.

Work with the IT Lead,

Business Lead and Vendor

PM to ensure the project

plan is set up and that

project tasks are tracked in

the PM scheduling tool.

Ensure PennDOT IT resources/tasks are included in the plan and that all IT resources are fully aware of their commitments to the success of the project.

Provide plan owner with project team commitment levels and task estimates as needed.

Ensure PennDOT business resources/tasks are included in the plan and that all business resources are fully aware of their commitments to the success of the project.

Provide plan owner with project team commitment levels and task estimates as needed.

Ensure all consultant

resources/tasks are included in the

plan.

Provide plan owner with project

team commitment levels and task

estimates as needed.

25


Project Plan

Maintenance Maintain project plan. Keep actual hours and task / milestone / deliverable progress current. Provide regular statistics on schedule (SPI or other approved measure of schedule).

Ensure timesheets are entered, reviewed and approved weekly.

Ensure timesheets are entered, reviewed and approved weekly.

Provide Project Manager with regular updates on status of consultant tasks.

Change, Risk,

Issue and Quality

Management

Plans

Ensure Project Management

plan is completed and that

controls are appropriate for

the size and complexity of

the project.

Ensure changes, issues and

risks are tracked and

assessed regularly. Ensure

escalation procedures are

working effectively.

Identify issues and risks.

Participate in quality reviews as

needed.

Ensure timely decisions are made

on any items requiring input from

IT resources.



needed.

Ensure timely decisions are

made on any items requiring

input from business resources.



needed.

Project

Deliverables

Ensure Deliverable Log is

updated regularly and track

progress of project

deliverables.

Ensure any deliverables that need

to be completed or reviewed by

the IT resources are completed per

the project schedule.

Ensure any deliverables that

need to be completed or

reviewed by the business

resources are completed per

the project schedule.

Ensure any deliverables that need

to be completed or reviewed by

the consultant resources are

completed per the project

schedule.

Budget Tracking Track and provide regular

statistics on project budget

(CPI or other approved

measure of cost).

Track budget for consultant

resources. Provide Project

Manager with regular updates.

AAR Conduct AAR. Participate in AAR. Participate in AAR. Participate in AAR

26


Lessons Learned Summarize and store

lessons learned

documentation.

Provide lessons learned. Provide lessons learned. Provide lessons learned

documentation.

27

Project Management Plan [Project Name Here]

Last Updated : <Date>

Version: <>

Prepared by: <Name>

<Project Name>

28


<Project Name>

29

Table of Contents

Document Purpose

Project Charter

Work Breakdown Structure (WBS)

Project Budget

Project Governance

Project Management Plans

Project Execution

Project Controls

<Project Name>

30

Document Purpose This document outlines the basic project management approach that will be followed for Level 1 IT

Projects.

All ‘blue’ instruction text should be removed before finalizing this document.

NOTE: PennDOT IT Standards and Templates are housed on the PMO Collaboration Site at www.portal.state.pa.us.

Project Charter Every PennDOT IT Project regardless of Level requires a Project Charter. The Charter

identifies the goals, objective and scope of the project. The Charter should be completed

before the WBS is developed.

Work Breakdown Structure (WBS)

Project Name: ___________________________________

<Describe briefly how project schedule will be tracked and reported for this project. Ex. Will all or some resources be recording time against this project in MS Project Online>

Project Budget

<Describe if and how budget will be baselined and tracked for this project.>

Project Governance PennDOT’s IT Governance Standard defines the way projects will be governed to ensure that

all requirements are met. These processes and procedures are used to escalate and resolve

issues, correct deficiencies, and make changes to Project scope if required. Project Governance

shall be conducted in accordance with the PennDOT Project Governance Standard.

The Project Manager will review the Project Governance Worksheet

http://www.portal.state.pa.us/portal/server.pt/gateway/PTARGS_0_425056_226_2166_408831_43/http;/collaboration.state.pa.us;11930/collab/do/project/overview;jsessionid=E3D5F52374E9E84E04C12D030038B428?projID=122851

http://www.portal.state.pa.us/

<Project Name>

31

Project Management Plans

Communication Plan

<The communication management plan identifies the required project communication through meetings and meeting artifacts. The logistics and frequency of meetings are defined below.>

Project Governance Committee (PGC) Meetings

Meeting Purpose Plan, review and monitor project status

Meeting Frequency Weekly

Meeting Logistics < Enter logistics regarding location of meetings, conference call etc.>

Scheduling Considerations < Enter any special scheduling considerations or requirements>

Emergency Meeting Logistics Any committee member can request the PMO Lead to schedule an emergency meeting.

Meeting Facilitator <Provide name – typically this is the PM>

Regular Meeting Invitees PEMT committee members (<List Names of Members>) <List others>

Meeting Minutes Recipients <List recipients>

Project Governance Committee Team Artifacts

Project Execution Management Team (PEMT) Meetings

Meeting Purpose Plan, review and monitor project status


Meeting Logistics < Enter logistics regarding location of meetings, conference call etc.>

Scheduling Considerations < Enter any special scheduling considerations or requirements>

Emergency Meeting Logistics Any committee member can request the PMO Lead to schedule an emergency meeting.


Regular Meeting Invitees PEMT committee members (<List Names of Members>) <List others>

Meeting Minutes Recipients <List recipients>

No Artifact Name

Artifact Purpose Responsible Resource

Distribution Method

Timing Expectations

Approval Procedure

1 Agenda The agenda describes what will be discussed during the meeting.

<PM Name> <Method > 24 hours prior to meeting

<PMO Lead >

2 Minutes Meeting Minutes document the discussion, decisions made during the meeting.

<PM Name> <Method > Within 3 working days after meeting

<PMO Lead >

3 Action Item Log

Any action items from this meeting will be added to the Action Item Log with a source of “PGC”


<PMO Lead>

4 PGC Status Report

Project report providing the current status of the project.

<PM Name> <Method > prior to meeting

Approved at meeting by PGC

<Project Name>

32

Project Execution Management Team Artifacts

Team Responsibility

Though the facilitator or designate, identified as the scribe, is responsible for documenting minutes,

issues, decisions and or action items, it is the responsibility of each member on the team to read the

minutes and check that all items were documented correctly. It is the team member’s responsibility

to let the scribe know of any miss-statements or omissions. They also have the responsibility to

know any issues or action items they have been assigned and when they are due.

Other Regularly Scheduled Project Meetings

<Provide detailed communication information regarding any other regularly scheduled meetings that will be held for the project. A similar level of detail as to what is provided for the PEMT and Governance Committee meetings should be provided>

Ad Hoc Meetings

Frequently, informal ad hoc meetings need to be held to discuss specific project issues or tasks. The

facilitator of each meeting, or other person designated by the facilitator, will at a minimum track

decisions and action items from the meeting. These are to be provided to the project team member

who will be responsible for following up on the issues and actions as well as the PM within 2 days of

the meeting. Whenever possible, the PM should be notified in advance of any meeting being held

for the project.

Stakeholder Management

<Describe here the stakeholder communication needs and how they will be addressed. If the stakeholder communication needs are extensive, a separate Stakeholder Management Plan should be created and maintained.>

No Artifact Name


Distribution Method

Timing Expectations

Approval Procedure


<PM Name> <Method > 24 hours prior to meeting

<PMO Lead >



<PMO Lead >

3 Action Item Log

Any action items from this meeting will be added to the Action Item Log with a source of “PEMT”


<PMO Lead>

4 Weekly Status Report


<PM Name> <Method > prior to meeting

Approved at meeting by PEMT

<Project Name>

33

Stakeholder Communication Need Communication Method

Responsible Person

<Name> <What information is needed by this stakeholder? >

How and when will this information be shared communicated?>

< Name>

<Name>

<Name>

Quality Management

Describe here the activities that will be undertaken to ensure that each deliverable meets or exceeds the requirements defined in the project charter and is acceptable quality.

No. Deliverable Name Specific Quality Activities Responsible Person

1 <Deliverable Name> <Quality Activity> < Name>

2

3

4

Configuration Management

Configuration Management shall be conducted in accordance with the PennDOT Project

Standards.

<Describe briefly how software configuration will be managed for this project.>

Procurement Management

Procurement Management shall be conducted in accordance with the PennDOT Project

Standards.

<Describe briefly the hardware, software and services that must be procured for this project, their due dates and how that procurement will be managed.>

Organizational Readiness

Organizational Readiness is the ability of the organization to fulfill obligations with regard to IT

projects by providing information technology, personnel, resources, information or knowledge in

a timely manner to make the project a success. In addition to items provided, organizational

readiness includes the organizations ability to receive, accept and use new information, tools,

capability, software, and process created by the project.

< Describe here how and what the organization must do to prepare for and realize the benefits of this project.>

<Project Name>

34

Project Execution

Weekly Project Status Reporting

Each week the PM must review assignments and track project progress per the approved project

plan. He/she shall do this by communicating with the Project Execution Team (PET) to ascertain

progress, and uncover issues and risks. The Weekly Status Report can then be prepared utilizing the

Status Report template provided for this purpose.

< Describe briefly the timing and approval process that will be used for this weekly report. Variations in status reporting format and/or frequency must be approved by the PMO Project Director.>

Document Management

Document Management shall be conducted in accordance with the Document Management

Standard.

Name of Project as depicted on the SharePoint site: ____________

< Describe here any special document management concerns for this project.>

Change Management

Change Management shall be conducted in accordance with the PennDOT Project Governance Standard. All Change Requests should be logged in the Change Request Log.

< Describe here any special change management concerns for this project.>

Project Controls Various logs will be used to help the PM control the project.

RAID Log

The RAID Log is a consolidated spreadsheet that includes the Risk, Action Item, Issue and

Decision Logs. The RAID Log should be used for each project and reviewed with the team on a

regular basis.

RAID Log will be reviewed by PEMT every _______ weeks.

Risk Log

The Risk Log shall be used to identify the major risks to the project. The PEMT should discuss

the potential risks to the project and provide both elimination and mitigation strategies for the

top threats on the Risk Log. All project risks will be captured and maintained on this log. If a

<Project Name>

35

risk is realized (comes to fruition) it is no longer a risk but an issue. If this occurs, the risk should

be moved to the Issue log for tracking and resolution.

Action Item Log

All project action items will be captured and maintained on this log. Action items that are not

completed in a timely manner that may have impact on the project delivery will be escalated as

issues per the IT Project Governance Standard.

Issue Log

Issue Management shall be conducted in accordance with the PennDOT Project Governance Standard, Level 1 Project. All project issues will be captured and maintained on this log. High priority issues must be resolved in a timely manner or escalated properly via the IT Project Governance Standard.

Decision Log

All key project decisions will be tracked on this log. Pending decisions that may affect project

delivery should be tracked as project issues.

Deliverable Log

All project deliverables will be tracked on this log. Deliverables that are not completed in a

timely manner that may have impact on overall project delivery will be escalated as issues per

the IT Project Governance Standard.

Deliverable Log will be reviewed by PEMT every ________ weeks.

Change Request Log

All changes to project scope, budget or schedule will be tracked on this log. Pending decisions that

may affect project delivery should be tracked as project issues.

36

Communication Plan <Project Name Here>

Last Updated : <Enter date here>

Version: xxx

Prepared by:

<Project Name>

37


11/5/14 1.0 Initial Draft PMO

11/20/15 1.1 Updated to remove reference to Executive Steering Committee and

<Project Name>

38

Table of Contents

Communication Overview

Status Reporting

Project Execution Management Team (PEMT) Meetings

Project Governance Committee Meetings

Other Regularly Scheduled Project Meetings

Ad Hoc Meetings

Outreach/Stakeholder Communication

Formal Contract Communication Recipient

Issue and Risk Communication and Management

Issue Escalation

Document Management

Project Team List

<Project Name>

39

Communication Overview <Blue text is provided for instruction only. Delete and set text color to black before completing document>

Effective communication is a key to project success. This document along with the <Project Name>

Project Governance document outlines the lines of communication for this project. The Project

Manager (PM), <PM Name here>, will ensure that this plan remains current and effective. The PM is

the primary point of contact for project communications. The PM should be the primary contact

for any project issue, concern or question regarding the project. This resource is responsible for

resolving, delegating or escalating these items.

If there is ever uncertainty as to who to contact regarding a project issue, concern or question. This

document outlines the various meetings and other communication tools that will be used for this

project. The table below provides a summary of this information.

Communication Recipient(s)

Communication Need Communication Action Responsible Resource

Execution Management Team

Regular detailed information sharing on project tasks.

- -Weekly Status Report

- -Weekly Meeting

- -Meeting Minutes

PM

Governance Committee

Apprised of project status including key issues and risks

- -Monthly Status Report

- -Monthly Meeting

PMO Lead has primary responsibility but PM provides project input.

Other Internal and External Stakeholders

Varied needs amongst stakeholders

Defined in Communication and/or Stakeholder Management Plan

PM responsible to ensure plan created and executed.

Table 1: Communication Overview

Please note that project communication does not replace the lines of communication already in

place for each business and IT functional area involved with this project.

Status Reporting As depicted in the table below status reports will be developed regularly for this project. Each will

follow the standard PennDOT format for project status reports.

Status Report Responsible Resource Timing

Weekly Status Report

PM <Enter timing

expectations i.e.

noon on Monday>

<Project Name>

40

Status Report Responsible Resource Timing

Monthly Status Report

PMO Lead has primary responsibility but PM provides project input.

<Enter timing

expectations i.e. COB

on 2nd Friday of each

month - Timing will

be related to the

timing of the

Governance

Committee

Meetings.>

Monthly Executive Portfolio Dashboard Report

PMO Project Director (PD)

By COB the 2nd Tuesday of each month.

Project Execution Management Team (PEMT) Meetings Meeting Purpose Plan, review and monitor project status


Meeting Logistics < Enter logistics regarding location of meetings, conference call

etc.>

Scheduling Considerations

Emergency Meeting Logistics

Any committee member can request the PMO Lead to schedule an emergency meeting.


Regular Meeting Invitees

PEMT committee members, BRRO Representative, Contract Manager

(<List Names of Members>)

<List others>

Meeting Minutes Recipients

<List recipients>

Project Execution Management Team Meeting Artifacts

No Artifact Name


Distribution Method

Timing Expectations

Approval Procedure


24 hours prior to meeting


Within 3 working days after meeting

3 Action Item Log

Any action items from this meeting will be added to the Action Item Log


<Project Name>

41

No Artifact Name


Distribution Method

Timing Expectations

Approval Procedure

4 Weekly Status Report


prior to meeting

Approved at meeting by PEMT

Project Governance Committee Meetings Meeting Purpose

Receive current status of project from PEMT including risk and

issue update.

Ask project managers and project leads questions to ensure a

thorough understanding of the status of the project.

Address and resolve issues that have been escalated to the Project

Governance Committee

Review project change requests and approve or reject such

requests.

Provide general guidance to project leads.

Recommend corrective action when needed.

Meeting Frequency Monthly

Meeting Logistics

Scheduling Considerations

Emergency Meeting Logistics

Any committee member can request the PMO Lead to schedule an emergency meeting.

Meeting Chairperson <Refer to the project Governance Document>

Meeting Facilitator <Typically this is the PMO Lead>

Regular Meeting Invitees

Meeting Minutes Recipients

Project Governance Committee Meeting Artifacts

No Artifact Name


Distribution Method

Timing Expectations

Approval Procedure


24 hours prior to meeting

Verbal PMO PD Approval before distribution




<Project Name>

42

No Artifact Name


Distribution Method

Timing Expectations

Approval Procedure

3 Action Item Log

Any action items from this meeting will be added to the Action Item Log with a source of “PGCM”


None

4 Monthly Status Report

Project report summarizing the current status of the project including updated Risk Analysis each month.

3 days prior to Meeting


Other Regularly Scheduled Project Meetings <Provide detailed communication related information regarding any other regularly scheduled meetings that will be held for the project. A similar level of detail as to what is provided for the PEMT and Governance Committee meetings should be provided>

.

Ad Hoc Meetings Frequently, informal ad hoc meetings need to be held to discuss specific project issues or tasks. The

facilitator of each meeting, or other person designated by the facilitator, will at a minimum track

decisions and action items from the meeting. These are to be provided to the project team member

who will be responsible for following up on the issues and actions as well as the PM within 2 days of

the meeting. Whenever possible, the PM and PMO Lead should be notified in advance of any

meeting being held for the project.

Outreach / Stakeholder Communication [If there are extensive and stakeholders for this project a separate Stakeholder Management Plan should be created and noted here.]

Communication Recipient(s)

Communication Need Communication Action Responsible Resource

<Project Name>

43

Formal Contract Communication Recipient Every project should have a formal contract communication recipient to be the recipient of any

formal project communication particularly when it relates to contractual items. This recipient can’t

be a consultant.

Issue and Risk Communication and Management An Issue Log (utilizing the PMO Issue Log template) will be used to record and track issues. The

project Issue Log will be stored in the project’s collaboration site so that it is available for all team

members. The Issue Log will be reviewed weekly at the PEMT meetings.

The most critical issues will be included in the project’s Monthly Status Report and presented to the

project Governance Committee on a monthly basis so that they are regularly informed of the

challenges the project is facing.

A Risk Log (utilizing the PMO Risk Log template) will be used to record, evaluate and track risks.

The project Risk Log will be stored in the project’s collaboration site so that it is available for all

team members. The Risk Log will be reviewed monthly by the PM at the PEMT meeting prior to

the Governance Committee Meeting. Once a risk is realized it should be tracked as a project issue.

The most critical risks will be included and updated each month in the project’s Monthly Status

Report and presented to the project Governance Committee so that they are regularly informed of

the challenges the project is facing.

Issue Escalation The PennDOT standard IT project issue escalation process is described in detail in the Project

Governance Standard Document. The PM, with support from the PMO, is responsible for ensuring

effective issue escalation. If issues or other project concerns arise on the project, the PM should be

the primary contact. He/she is then responsible for ensuring that the appropriate escalation is

applied.

Document Management The project’s documents are an important component of project communication and need to be

stored in an organized fashion where all team members can access them. All project documents

including deliverables, meeting minutes and agendas will be stored on the Enterprise SharePoint

Portal at https://spportal.dot.pa.gov within the Project Site.

https://spportal.dot.pa.gov/PMO/Pages/default.aspx

<Project Name>

44

A separate Document Management Plan regarding documents related to the project will be created;

however, this Communication Plan provides guidance on who has access to these important

documents.

SharePoint Site Access The list of individuals that have access to the SharePoint site is provided below:

Name Owner Member Guest

Name x

Project Team List The project team and their primary project roles are provided below. Contact information for each

person is available in the Commonwealth’s Outlook directory.

<Note: If team members are not listed in the Commonwealth’s Outlook directory, contact information should be provided in this section of the document.>

Name Primary Project Role

45

Quality Management Plan <Project Name Here>

Last Updated : <Enter date here>

Version: xxx

Prepared by:

<Project Name>

46


<Project Name>

47

Table of Contents

Project Quality

Review Process by Deliverable Type

Deliverable – Review Schedule and Acceptance Log

<Project Name>

48

Project Quality

Quality Management Plan Objectives

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

The objectives of this plan are to ensure the following:

1. Adherence to the procedures standards, and processes required by PennDOT.

2. To insure customer satisfaction. Customer satisfaction is a key measure of success of a

project, along with completing the project on time and within budget.

3. To reduce time-consuming errors. Fixing errors takes time that can make the project go past

deadline.

4. To avoid operational issues. Addressing errors and unresolved issues after the project is

handed over to an operational entity can compound the adverse effects, resulting in lawsuits,

complaints, system down time, and unexpected costs.

5. All work products are accurate and complete.

6. All work products provide the information required by the project team and expected by the

customer

The successful accomplishment of these objectives reduces the risk of unforeseen schedule slippage, miscommunication with the customer, and delivery of defective products.

Carrying out the Quality Plan Objectives

1. Assess project quality regularly during the Execution and Control phase using quality assurance tools such as:

structured walkthroughs (peer reviews) of formal project deliverables

in-stage assessments (in-process independent "technical" reviews) during production of the deliverable

testing strategies

configuration management

change control

periodic QA reporting

<Project Name>

49

2. Conduct quality control activities continually throughout the project to prevent and fix errors and insure quality standards are being met. Use an error report form for consistent reporting.

3. Verify and validate that deliverables are of acceptable quality and that they meet the completeness and correctness criteria established in the quality management plan.

Quality Assurance

Quality assurance does not refer directly to specific deliverables. It refers to the process used to create the deliverables. In general, quality assurance activities focus on the processes being used to manage and deliver the solution and can be performed by a manager, customer, or a third-party reviewer. Examples of quality assurance include process checklists, project audits and stage gate approvals.

Quality Assurance Procedures, Tools, Responsibility

<List the major quality assurance activities that will be performed on this project. These should be included in the project plan as tasks/milestones.> <List any quality-related tools that this project will utilize. This could include standard spreadsheets and templates, software tools, and development packages. A Corrective Action Log (PMO Template) is a required tool.>

QA

Procedure

ID

QA Procedure Description Tool Used Responsible

QA1 Configuration Management

Plan

As identified in the

Configuration

Management Plan

<name here>

QA2 Monitor and Record and

corrective actions taken

Corrective Action Log <name here>

QA3 <name here>

<Project Name>

50

Quality Control

Quality Control refers to the activities associated with the creation of project deliverables. It is used to verify that deliverables are of acceptable quality and that they meet the completeness and correctness criteria established in the quality planning process. Examples of quality control activities include deliverable peer reviews and the testing process.

Quality Control Procedures and Tools, Responsibility

<List the major quality control activities that will be performed for this project. These should be included in the project plan as tasks/milestones.>

QC

Procedure

ID

QC Procedure Description Tool Used Responsible

QC1 <name here>

QC2 <name here>

QC3 <name here>

Deliverable Quality Review Responsibility Table

The project charter lists the project deliverables and the individual or group that is responsible for final review and sign-off. The deliverable list is repeated here to:

Identify those responsible for the initial and interim deliverable reviews.

Indicate the interim review dates.

Del

No.

Deliverable Name Initial Review Interim Review Final Review

D1 <responsible

name here>

< responsible name

here>

< responsible

name here>

D2 < responsible

name here>

< responsible name

here>

< responsible

name here>

D3 < responsible

name here>

< responsible name

here>

< responsible

name here>

<Project Name>

51

Deliverable Types

In general, deliverables fall into one of four categories. These include: Code, Document, (all types of system requirement, design, test, etc.) Database (development or change) and Report (development or change.) Other categories may be identified and added to this list as appropriate but the table below must be expanded to identify the initial, interim and final review criteria to ensure the quality of the deliverable meets the goals and objectives of the project as identified in the Project Charter.

Initial and Interim Review

The purposes of the initial and interim review are to ensure that the quality of the deliverable is established early in its creation, and is tracking to meet expectations during its interim development. The Review Process by Deliverable Type table below outlines what the reviewer should be looking for as they review the deliverable. The Deliverable Review Schedule and Acceptance Log (see below) identified the reviewers for the Initial and Interim Reviews, establishes dates for the reviews and provides a place for the reviewer to initial acceptance enter the acceptance date.

Final Review before delivery

The purpose of the final review is to ensure each deliverable meets its established purpose and is of acceptable quality before delivery.

<Project Name>

52

Review Process by Deliverable Type Deliverable

Type

Initial Review Interim Review Final Review before

delivery

Code In the initial review of code, the reviewer should

ensure that any applicable technical standards

are being followed and that the code is being

developed based on the System Requirements

Specification with no expansion of scope.

In the second review of code, the reviewer

should ensure any applicable technical standards

are being followed, that the code is being

developed based on the System Requirements

Specification with no expansion of scope. That

the code is elegantly written and appropriately

commented.

In the final review of

code, the reviewer

should ensure that all

final acceptance criteria

have been met.

Document In the initial review of a document, the reviewer

should be looking at the outline structure and

any content. This review should not focus on

grammar, misspellings or formatting. The

objective is to ensure the outline and structure of

the document is complete and any content is

correct.

In the interim review of a document, the

reviewer should be looking at the content to

determine it is correct. Any glaring formatting or

grammatical errors should be pointed out but this

is not the focus of the review.

In the final review of a

document, the reviewer



have been met.

Database In the initial review, the reviewer should ensure

that all applicable technical standards are being

followed. In the case of a DB change, verify that

an impact review has been conducted to

determine what other applications may be

affected by changes to the DB.

In the interim review of the DB, the reviewer

should ensure that all applicable technical

standards are being followed. That the DB

construction or change is following best industry

standard practice.


database change, the

reviewer should ensure

that all final acceptance

criteria have been met.

Report In the initial review of a report, the reviewer


standards are being followed, That the design

layout of the report is understood.

In the interim review of a report, the reviewer


standards are being followed. That the design

layout of the report has been followed.


report, the reviewer



have been met.

<Project Name>

53

Deliverable - Review Schedule and Acceptance Log Del

No.

Deliverable

Name

Type Initial

Review

(Date)

Accepted

By:

(Initial

below)

Initial

Review

Acceptance

(Date)

Interim

Review

Acceptance

(Date)

Accepted

By :

(Initial

below)

Interim

Review

Acceptance

(Date)

Final

Review

(Date)

Final

By:

(Initial

below)

Final

Review

Acceptance

(Date)

1 Deliverable

Name Here

Document

2. Deliverable

Name Here

Code

3 Deliverable

Name Here

DB

4 Deliverable

Name Here

Report

54

Document Management

Standard

Last Updated: 1/16/2012

Version: 1.8

Prepared by: PennDOT IT PMO

Document Management Standard

55


5/17/2011 1.7 Original Version PMO Team

1/16/2011 1.8 Updated security definitions, edit properties, updated check in/check

out, creating links, minor wording changes

PMO Team


56

Table of Contents

Document Management

Document Management Roles and Responsibilities

Document Management Plan

Project Librarian

Project Collaboration Site

Document Naming Conventions

Document Control

Using the Project Collaboration Site


57

Document Management Document Management is an important part of managing, monitoring and evaluating project performance and results. Documents must be stored where they are accessible to all team members and they must be handled and named in a consistent manner. It is expected that the majority of project documents will exist in an electronic format and the majority of this section is focused on those documents. However, similar rigor is required for ensuring proper management of hardcopy documents that are part of a project’s document library.

Document Management Roles and Responsibilities

Every member of the project team is responsible for following the document management’s procedures and standards put into place for the project. In addition a single person, a project librarian, should be designated for each project.


Each project should have a Document Management Plan which at a minimum identifies the project librarian, document storage standards for both electronic and hardcopy project documents, document naming conventions and the document control procedures that will be put in place for the project

Project Librarian

The Project Librarian has primary responsibility to ensure that project documents are stored correctly in the project library. This includes receiving and tracking deliverables, ensuring that other project documents are correctly stored in the project collaboration site. The Librarian is also responsible for the project’s records retention policies and archiving hardcopy documents, as appropriate.

Project Collaboration Site

PennDOT has decided to utilize a web-based project collaboration tool as a document repository during the IT Project Lifecycle. This web-based tool is easy to use and provides internet-based access from any standard web browser (with proper authorization), easy to use interface, and version control.

A SharePoint site must be set up to house important project documentation. This provides a common location and folder naming convention where all authorized participants will have continual access to the documents and be able to find them easily. The site shall utilize the standard file folder structure as defined in the SharePoint Standard IT Document Management Structure. It is intended that the SharePoint site, the folder structure, and other standards described in this document shall apply to all PennDOT IT Studies, as well as Level 1, 2 and 3 IT Projects.

https://spportal.dot.pa.gov/sites/PD_PMO_IT/PMODocuments/PMO%20Handbooks%20and%20Standards/SharePoint%20Standard%20IT%20Document%20Management%20Folder%20Structure.doc

https://spportal.dot.pa.gov/sites/PD_PMO_IT/PMODocuments/PMO%20Handbooks%20and%20Standards/SharePoint%20Standard%20IT%20Document%20Management%20Folder%20Structure.doc


58

Setting up a SharePoint Site

To request a SharePoint Site, please contact the PMO at [email protected] or fill out a site requisition form on the enterprise SharePoint portal.

Standard File Folder Structure

In an effort to drive consistency and make it easy for authorized personnel to find and access documents, every project will utilize a consistent file folder structure as shown in

mailto:[email protected]

https://spportal.dot.pa.gov/_layouts/FormServer.aspx?XsnLocation=https://spportal.dot.pa.gov/Project%20Requisition/Forms/template.xsn&SaveLocation=https%3A%2F%2Fspportal%2Edot%2Epa%2Egov%2FProject%20Requisition&ClientInstalled=true&DefaultItemOpen=1


59

below. These standard folders will be created for each project site to categorize/organize the documents. The folders on each project site are designed to house all the project artifacts and deliverables. A brief description of the expected contents for each folder is provided in Figures 1and 2 below.

Note: No one should remove folders or make changes to the top level folder structure unless you have received approval from the PMO Director.


60

Background &

Procurement

Project Folder

Charter and All Project Plans

Historical Data, Work Orders,

RFPs/RFQs and SOWs

Lessons Learned and

After Action Reviews (AARs)

Key Points:

1) Titles of pages will provide brief

description of documents to be stored in

that location.

2)“In Progress” working documents can

be saved in SharePoint as Draft.

SharePoint Standard IT Project Folder Structure

Meeting Agendas\

Minutes (Add folders as

neceesary)

Project Schedules and

Timeline Snapshots

Risks, Action Items, Issues, Decisions

(RAID) Log and Change Requests

Requirements Documentation

Design and Development

Documentation

Testing Documentation

Implementation Documentation

Charter & Project

Plans

Schedules &

Timelines

Meetings & Status

Reports

RAID Log & Change

Requests

Requirements

Design &

Development

Testing

Training &

Outreach

Implementation

Lessons Learned

& AARs

Status Reports

Meetings

Status Reports

PGC

PEMT

PGC

PEMT

Training Documentation

Newsletters, Press Releases,

Brochures and Other Correspondences

Training

Outreach


61

Figure 1: Standard Project Collaboration Site Folder Structure

Folder Name Expected Contents

(Note: Not every document listed below is relevant to every project.)

Background &

Procurement

Documentation from Project Definition Phase.

Project Scaling Worksheet

Other background information needed for the project that should be available to the team for reference

The final RFP/RFQ and any other Procurement or Work Order documents

Other documents related to the procurement process for this project that should be available to the team for reference.

Schedules & Timelines Project Schedules

Weekly/Monthly Project Timeline Snapshots

Charter & Project Plans Project Charter

Project Management Plan

Communication Plan

Quality Management Plan

Project Governance Document/Worksheet

Risk Management Plan

Stakeholder Management Plan


Configuration Management Plan

Other project planning documents that should be available to the team.

RAID Log & Change

Requests

RAID (Risks, Action Items, Issues, Decisions) Log

Deliverable Tracking Log

Project Change Request Log

Project Change Requests

Other project control documents that should be available to the team.

Meetings and Status

Reports

Meetings

PGC PEMT Other

Meeting Agenda

Meeting Minutes

Other Meeting Materials

Additional folders can be added as needed to meet the project needs.

Status Reports

PGC PEMT Other

Weekly Status Reports

Monthly Status Reports

Additional folders can be added as needed to meet the project needs.

Requirements Requirements documentation and approved requirements deliverables

Design & Development Design & development documentation and approved design & development deliverables

Testing Testing documentation and approved testing deliverables


62

Folder Name Expected Contents

(Note: Not every document listed below is relevant to every project.)

Implementation Implementation documentation and approved implementation deliverables

Training & Outreach Training documents and approved deliverables

Newsletters, Press Releases, Brochures, and Correspondences

Lessons Learned &

AARs

PM’s Lessons Learned Log and AAR Documentation

Study-Stage-Project Closure Document

Figure 1: Description of Standard File Structure

*Please note that PMO Templates are not added to a project SharePoint site when the site is

created. The templates folder in the PMO Documents SharePoint Site contains templates that

may be downloaded and used for your projects.

Project Site Access

Those team members who have access to the project site will be documented in the Project Communication Plan. Typically a site will be initially set up such that the PMO PM has Owner Access, the Execution Management team has Member Access and the Governance Committee has Visitor Access. All authenticated users have visitor access to PMO project sites, by default. The Project Manager should work with the PMO to ensure that each team member has the appropriate level of access.

Visitor Access

(Read)

Member Access

(Contribute)

Owner Access (Full Control)

Projects View Project, List

items

Create alerts

View Project

Create alerts

Edit items in lists

Create, Delete, Approve and

Edit Lists

Add and Customize Pages

Modify Project Security

Settings

Create Subsites

Folders View Folders

Modify folder properties

Rename folders

Copy folders

Create folders

Delete folders

Move folders within the project

Configure folder security

Note: No one should remove

folders or make changes to the

https://spportal.dot.pa.gov/sites/PD_PMO_IT/PMODocuments/PMO%20Templates%20and%20Tools/Forms/AllItems.aspx


63

Note: No one should

remove folders or make

changes to the top level

folder structure unless you

have received approval from

the PMO Director.

top level folder structure

unless you have received

approval from the PMO

Director.

Documents View items in lists

and documents

Notify other users

about the file

View versions

Download

documents

Attach task lists and

discussions

Modify file properties

Create shortcuts

Publish to SharePoint site

Edit items in lists and

documents in document

libraries

Copy files

Approve files

Add/Delete files

Move files

Configure file security

Remove owner security

settings from a document

Force Check-In Documents

Document Naming Conventions

A consistent file naming convention goes hand-in-hand with a uniform file structure making it easy to quickly locate the desired file. The objective is to use a naming convention that provides enough information for the user to be sure they have located the desired file without having to open that file to check its contents, version, etc.

There are two basic file types. Time based documents such as agendas, meeting minutes and status reports, the second are non-time-based documents.

Preferred Time-Based File Naming Convention

Indicate the date first. Ex. 20090530 (YYYYMMDD)

Indicate the project name. This can be an acronym. Ex. ECMS

Indicate what type of document it is. Ex. Monthly Status

Try to keep the entire length around 32 characters including periods and file extensions if possible.

Good filename examples include:

20080625 AVL Monthly Status.doc

20090521 DB2 Upgrade PEMT Agenda.doc

20090307 ITS Gov Com Meeting Mintues.doc


64

Preferred Non-Time Based File Naming Convention

Indicate the project name first. This can be an acronym. Ex. ECMS

Indicate what type of document it is. Ex. Risk Plan

Try to keep the entire length around 32 characters including periods and file extensions if possible.

Good filename examples include:

AVL Communication Plan.doc

DB2 Upgrade-Risk Plan.doc

ITS Risk Plan.doc

Things to avoid

Poorly worded or vague descriptions

Not enough detail

Meaningless descriptors (or ones that only mean something to you)

Using dates at the end of a non-time-based file

You may not use “&” and “_“ in document names.

Bad filenames examples include:

Final Version of the plan.doc

Joe’s_Doc.doc

AVL –March.xls

VMRO2009.ppt

NOTE: It is very important that you DO NOT add dates to Non- Time Based files or change the filename or the versioning SharePoint assigns to the file will be lost, and the hyperlink will change.

For instance: DO NOT use a date to identify a revision - e.g. Action Item Log- 5.12.09 (and continuing to use this process to update and post new versions)

If a file name needs changed, right click on the file name and select Edit Properties. Never delete a file and upload a new one because version history will be lost.


65

Finally, there are some symbols and reserved characters that must not be used in filenames. Consult your computer Operating System requirements for a list of characters to avoid.

Document Control

Baselining a Document

Every project deliverable document should have a table at the beginning designed to track the changes as it develops and changes (through the review process and after it has been approved). This table includes columns for the Date, Version number, Description of the Changes and the Author/Editor. This table should be updated any time the document has been changed.

Draft documents that have not yet been finalized and approved should be marked with version levels < than 1.0. For example: The initial draft may be marked Version 0.1 with subsequent updates marked Version 0.2, Version 0.3, etc. Once the document has been approved, the table should be reset to Version 1.0 and the document identified as the “Approved Version” in the description section of the table. Please see an example of the Version status table below.


1/15/09 1.0 Approved Version J. Brown

Versioning a Controlled Document

Once the document has been approved, it should never be updated without appropriate update and specific comments in the Versioning Table.

Small Changes to Documents

For small document changes that do not require the document be reviewed and approved the revision number moves up by one tenth. In the example below, Mr. Smith added a note to the review policy in Section 2. This version moves from 1.0 to 1.1.



1/24/09 1.1 Added note to review policy in Section 2 T. Smith

Large Changes to Documents


66

When the changes to the document are significant and do require review and approval, the approved version number moves up to the next highest whole number. In the example below, Mr. Smith revamped the organizational structure. This version moves from 1.0 to 2.0.



1/24/09 2.0 Document revamped to include new organizational

structure and policy changes

T. Smith

Using the SharePoint Site

Editing a Document

Check In - Check Out Method

The SharePoint site provides a check in /check-out functionality to control changes, and

maintain version levels as the documents develop and mature. To use this method of

document editing:

Select the file and select “Check Out” on the Documents button bar or click on the arrow to the right of the document name and select “Check Out”. Another method is to select the file name and open the document. A dialog box will appear asking if you would like to open the file read only or check out and edit. Select check out and edit. You can also open the file read only, and then check it out using the checkout button below the button bar.

When you have checked out your document and made your changes, save your document. Clicking the File tab will take you to the Info screen. Click the Check In button to check in the document and save your changes. If you do not have any changes and want to undo your checkout, select the discard check out button.

After checking in the document, the version number will be automatically incremented and the modified date and time will be updated along with modified by.

When applicable, use the check in comment to indicate what was updated in the document.

NOTE:

Do not delete a document (unless it was added in error). Check the file out, make

changes, and check the file in. If you delete the document, all version history is lost.

You should never upload a new version of an existing document. Always Check

Out/Check In the updated document.


67

If you need to cancel the Check Out, Click on Discard Check Out Icon on the menu

ribbon.

Viewing a Document

The SharePoint site provides you with the ability to view a document.

Left click on the document you want to view.

A box will appear and ask if you would like to open the file in read only mode or check out and edit. Choose the read option and view the document.

When you are done viewing the document close the file.

NOTE: Any changes you make to a document while in read-only mode will not be

saved.

Viewing Version History

Click the checkbox next to the file you want to check the version history of.

Click on the arrow to the right and select Version History.

This will display all prior versions on the document.

There are options to revert to a prior version or delete a prior version

Creating a Link to a File

Right click on the filename appearing in the main content area

Select Copy Shortcut

You can now paste this URL into your email or document.

Moving a File

Check out your document.

Select your document and then the Library tab

In the Connect & Export group on the button bar, select Open with Explorer

Cut your file, navigate to the proper folder in Windows Explorer and paste.

Close the Explorer window.

Navigate to the new location of your file, and then check in the document.


68

Note that if you previously created any links to the document, they will no longer work, as the link goes to a location, not a document ID.

Sending Email Notifications of Document Changes

Use the Alert Me button on the library tab to set up email notifications when a document is

changed. You can set notifications up at the document or the library level.

69

Project Change Request

Project Name

Request No. Requested by

Document Revision Status

Revision Date Description of Changes Author/Editor

1.0 9/30/08 Original Version

Executive Summary

70

[In this section describe the core of the Change Request for executive consumption. What does the change involve? Why does this

change have to be made now? No more than one page.

Change Request Description

[In this section describe the Change Request. What does the change involve? Why does this change have to be made now?]

Priority and Impact if Change is Not Implemented

71

HIGH

MEDIUM

LOW

[What will happen if this change is not implemented? List specific impacts to

the project, and it desired outcomes.]

Change Impact Analysis

Project Area Y or N? If yes, detail impact

Cost Insert Y

or N

[Detail the impact of making this change on the project from a Cost Perspective]

Schedule Insert Y

or N

[Detail the impact of making this change on the project from a Schedule Perspective]

Resources Insert Y

or N

[Detail the impact of making this change on the project from a Resources Perspective]

Requirements Insert Y

or N

[Detail the impact of making this change on the project from a Requirements

Perspective]

Goals/Objectives Insert Y

or N

[Detail the impact of making this change on the project’s Goals and Objectives]

Deliverables Insert Y

or N

[Detail the impact of making this change on the project’s Deliverable(s)]

Risk Insert Y

or N

[Detail the impact of making this change on the project from a Risk Perspective]

Other Projects Insert Y

or N

[Detail the impact of making this change on the project to other projects]

Recommendation for Resolution

[Here describe the recommended change(s). Provide a specific bulleted list.]

Business or Technical Justification

72

[Why is this change justified from a business and /or technical perspective?]

Change Request Resolution

Responsibility and Authority for the review and approval of change requests vary with the project

level and are defined in the IT Project Governance Document and Final Project Charter.

Change Request Decision

□ Approved □ On Hold □ Denied

Decision Date

Signed:

Comments: