Project Management Methodology - Addendum A (as of 12/05/19€¦ · • PMM-0102: Project Management Plan • PMM-0104: Project Closure Report If a ustomers / Stakeholders name is

pg. 1

STATE OF MICHIGAN

PROJECT MANAGEMENT METHODOLOGY

ADDENDUM A

Michigan Department of Technology,

Management & Budget www.michigan.gov/SUITE

Issue Date: Dec. 1, 2019

Effective Date: January 1, 2020

Effective: FY20 Projects, All New Projects in progress for phase that you are on.

Version 1.0

http://www.michigan.gov/SUITE

pg. 2

pg. 3

Contents REVISION HISTORY ........................................................................................................................................ 3

Preface .......................................................................................................................................................... 4

INTRODUCTION ............................................................................................................................................. 5

1. DELIVERABLE APPROVAL / ACCEPTANCE ....................................................................................... 10

2. STAGE EXIT SIGN-OFF ..................................................................................................................... 13

3. STRUCTURED WALKTHROUGH REVIEW AND SIGNOFF .................................................................. 14

4. PROJECT CHARTER ......................................................................................................................... 15

5. PROJECT CLOSURE REPORT ............................................................................................................ 16

6. PROJECT BUDGET ESTIMATE .......................................................................................................... 18

7. RISK MANAGEMENT PLAN ............................................................................................................. 20

8. ISSUE MANAGEMENT PLAN ........................................................................................................... 22

9. PROJECT PERFORMANCE MONITORING ........................................................................................ 24

10. CORRECTIVE ACTION PLAN .......................................................................................................... 26

11. CHANGE REQUESTS ...................................................................................................................... 27

12. LESSONS LEARNED ....................................................................................................................... 29

13. PRODUCT AND QUALITY ASSURANCE (PPQA) PROGRAM / PROJECT QUALITY ASSURANCE (PQA)

............................................................................................................................................................ 32

14. PROJECT TAILORING ..................................................................................................................... 33

REVISION HISTORY

Revision Date Section(s) Summary

pg. 4

PREFACE Purpose

This is an addendum to the fourth edition of the Project Management Methodology (May 2014). The changes associated with this Addendum will be incorporated into the 2020 edition of the Project Management Methodology, which will be delivered in 2020. Changes and improvements to all SUITE processes, including this guide, are a result of user input. Send improvement suggestions to:

[email protected].

Changes in this addendum apply to the fourth Release (May 2014) of the PMM.

Project Management Methodology (PMM) is a key component of the State Unified Information Technology Environment (SUITE) and establishes formal project management practices. The methodology is sufficiently generic for use in all projects within the State of Michigan (SOM). It is transferable from project to project but is not intended to be the sole source of information on project management.

Methodology Benefits and Compliance

This methodology is based on industry best practices and provides in-depth guidance for the entire project life cycle.

SOM Administrative Guide Policy 1355 requires statewide compliance and applies to all executive branch departments, agencies, trusted partners, boards or commissions using the State of Michigan information technology resources.

In accordance with 1355.00, Project Management Methodology Policy, specific guidance, and standards and processes, about the State Unified Information Technology Environment (SUITE) can be found on the following websites:

• SOM public facing SUITE website.

• SOM internal facing SUITE SharePoint site.

The Project Management Methodology manual and related forms are posted on these two sites. This addendum will be stored on both sites to ensure that changes to the PMM standards and procedures are communicated.

mailto:[email protected]

http://michigan.gov/suite

https://statedofmichigan.sharepoint.com/sites/epmo/suite

pg. 5

INTRODUCTION The Project Management Methodology (PMM) Addendum A is being issued to clarify guidance across

multiple sources, communicate changes introduced by Clarity and respond to recent customer

requests. Addendum A also addresses some of the key findings associated with the IT Project

Management Processes Audit by the Office of the Auditor General.

For purposes of the Addendum A Summary, a deliverable represents a SUITE document, SUITE

process, Clarity attribute and/or field. A summary of the changes is presented below:

1 – APPROVAL AND / OR ACCEPTANCE PROCESSES:

Addendum A provides additional options for the Project Management Methodology (PMM)

deliverables approval process. Approval / Acceptance of project deliverables are required to be

obtained in one of the following ways:

• Signature on deliverable

• Electronic signatures on deliverable

• Email approval embedded in / attached to the deliverable

• Email voting approval embedded in / attached to the deliverable

• Workflow approval (when available and supported by an audit trail)

The PMM deliverables requiring approvals include:

• PMM-0101: Project Charter

• PMM-0102: Project Management Plan

• PMM-0104: Project Closure Report

If a Customer’s / Stakeholder’s name is identified on the deliverable approval / acceptance form,

that individual or designated representative must approve by one of the methods identified above.

The project manager is responsible to ensure that these approvals are captured. Justifications for

deviations must be documented and are subject to Project Quality Assurance (PQA) review.

2 – STAGE EXITS:

A Stage Exit authorizes the project manager and team to proceed to the next stage of the project or

close the project. Stage Exits will be performed in conjunction with deliverable approval /

acceptance. This change streamlines deliverable approval / acceptance by combining deliverable

sign-off and stage exits where possible. PMM stage exits will be conducted as follows:

• Initiation / Planning – Initiation and Planning stage exit approval can be performed in

conjunction with the PMM-0102: Project Management Plan

• Execution – Execution stage exit will be performed, as before, when all project execution tasks

have been completed. The Project Manager will send notification that the Execution Stage is

complete via the Portfolio Project Management Tool

• Closure – Closure Stage exit approval will be administered in conjunction with the PMM-0104:

Project Closure Report

pg. 6

Project Managers and Project Teams can combine approval / acceptance as described above or

continue to collect suitable separate deliverables to a given project.

3 – STRUCTURED WALKTHROUGHS:

Structured Walkthroughs are performed to confirm quality, completeness and accuracy of

deliverables. The Structured Walkthroughs are performed in conjunction with the deliverable

approval acceptance. This change streamlines the Structured Walkthroughs approval / acceptance

by combining form / deliverable sign-off and structured walkthrough sign-off where possible. PMM

structured walkthroughs will be conducted as follows:

• PMM-0101: Project Charter – Project Charter Structured Walkthrough will be combined with

acceptance / approval of PMM-0101: Project Charter

• PMM-0102: Project Management Plan – Project Management Plan Structured Walkthrough

will be combined with acceptance / approval of PMM-0102: Project Management Plan

• PMM-0104: Project Closure Report – Project Closure Report Structured Walkthrough will be

combined with acceptance / approval of PMM-0104: Project Closure Report

Project Managers and Project Teams can combine Structured Walkthrough approvals / acceptances

as described above or continue to collect separate suitable deliverables to a given project.

4 – PROJECT CHARTER REQUIRED:

• Ensures that all projects have a PMM-0101: Project Charter to authorize the project manager to

proceed with the project

• A Statement of Work (SOW), Service Level Agreement (SLA) or Memorandum of Understanding

(MOU) may not be substituted for a Project Charter

• A project charter needs to be written to reflect the total scope of work that is required by the

project from both the vendor and the state

• The SOW, SLA and /or MOU may be referenced in the Project Charter to avoid duplication

5 – PROJECT CLOSURE REPORT:

Provides updates to the PMM-0104: Project Closure Report to include additional instructions for

invoice approvals and the Investment Management (IM) performance section:

• Guidance in PMM section 6.4-Close Financial Records and Contracts ensures that project

manager obtains signoff on all invoices available as of project close, then updates the PPM tool

before closing the project. After invoices are reviewed and approved, the project Cost Plan will

be updated to reflect approved invoiced project costs. In situations where invoices continue to

be processed following project close, the project manager is responsible for documenting the

party responsible for invoice approvals in the Closure Report.

• New PMM Section Investment Management Performance has been added to ensure that the IT

Investment is captured and tracked starting in the Initiation and Planning Stage through the

Project Close Stage.

• Project Investment Management Performance ensures that the following information is

captured in the project closure report:

• Return on Investment (ROI) Estimate, at the IDEA, and the Initiation and Planning Stage

pg. 7

• Anticipated Return on Investment (ROI), at Project Close

• Variance in Return on Investment (ROI), at Project Close

• Explanation of Return on Investment (ROI) Variance

6 - PROJECT BUDGET ESTIMATE:

• The Project Budget Estimate, which is created in PPM Tool as a Cost Plan, will include all

known project cost estimates

• To the extent possible, the project manager will estimate project cost for each cost category

as defined in the PPM Tool by creating line items for cost type(s)/transaction type(s)

• Upon approval, the cost plan becomes the Cost Plan of Record and is the project budget

estimate

7 - RISK MANAGEMENT PLAN:

The following elements must be included in a risk response strategy in the PPM Tool:

• Responsible person

• Tasks, activities

• Target completion dates

This information should reflect the risk management and risk mitigation action steps. All project

risks should be closed in the PPM Tool during the Project Close Stage.

8 – ISSUE MANAGEMENT PLAN:

The following elements must be included in the issue description in the PPM Tool:

• Description


• Tasks, activities


This information should reflect the issue management and issue resolution action steps. All project

issues should be closed in the PPM Tool during the Project Close Stage.

9 – PROJECT PERFORMANCE MONITORING:

Project Managers will follow guidance as issued in the September 30, 2019 Clarity Connections –

Changes to Project Status Criteria. As a result of input from the PMO Managers, Clarity's project

scoring is being adjusted to better align the Overall Status with our existing SOM Project

Performance Criteria. With this change, any one of the three indicators (Schedule Status, Scope

Status and Cost and Effort Status) set to Yellow/Red will trigger the Overall Status of the project to

Yellow/Red.

10 – CORRECTIVE ACTION PLAN:

Documentation requirements for corrective action plans, requires that responsible party (owner),

tasks, activities and target dates be documented in the PPM Tool. This information should be

reviewed and updated on a regular basis ranging weekly to monthly based on the duration of the

project and the complexity of the corrective action plan. Information should be included to reflect

https://stateofmichigan.sharepoint.com/:x:/r/sites/epmo/suite/Documents/SOM%20Enterprise%20Project%20Performance%20Criteria.xlsx?d=w860988bdde4b445e8a96ba2810224510&csf=1&e=2hMFgH

https://stateofmichigan.sharepoint.com/:x:/r/sites/epmo/suite/Documents/SOM%20Enterprise%20Project%20Performance%20Criteria.xlsx?d=w860988bdde4b445e8a96ba2810224510&csf=1&e=2hMFgH

pg. 8

action steps to move a project to ‘green’ status. The following elements must be included in list

action items needed to return to green:


• Corrective actions


11 – CHANGE REQUEST MANAGEMENT:

Documentation requirements for change requests guide that the change request be defined,

including impact assessment. Once change request has been approved and closed, the Cost Plan,

Budget Plan of Record, Benefits Plan of Record and Schedule baseline will be updated to reflect the

change. The following elements must be included in a change request description in the PPM Tool:

• Change request description

o Owner (Responsible Person)

o Tasks, activities

o Target completion date for tasks

• Expected Close Date

• Impact Assessment Fields: (Currently: Impact of Not Implementing the Change, Change in

Cost, Change in Schedule, Change in Resources, Impact on Baseline, Impact on Other

Projects, and Impact to Benefits Plan)

An attachment to the Change Request in the PPM tool can be added when further detail is needed.

All project Change Requests should be closed in the PPM tool after the change is implemented.

12 – LESSONS LEARNED:

• Lessons Learned will begin with the Initiation and Planning Stage and continue through the

Close Stage. As a new project starts, the project team will consult the lessons learned

database and leverage key learnings documented from other projects.

• The Project Manager will continue to confirm and complete Lessons Learned throughout all

project stages.

13 - PRODUCT AND PROCESS QUALITY ASSURANCE (PPQA) PROGRAM/PROJECT QUALITY

ASSURANCE (PQA):

All projects and programs are subject to PPQA/PQA Reviews. The PPQA/PQA team will establish,

maintain and communicate clearly stated criteria for evaluations of processes and work products.

The current list of items subject to PQA Review is posted on the SUITE SharePoint Site. The current

PPQA criteria is being expanded to cover:

• Items referenced in the Project Management Methodology Addendum A

• The Clarity Portfolio Project Management Tool Core 24

• Completed deliverables in accordance with PMM

The project managers are notified of non-compliance found during the review and are required to

correct the item or create a Corrective Action Plan to remediate non-compliance findings. When

applicable, lessons learned will be identified and documented by the project manager to ensure that

processes are improved for future products and services.

pg. 9

14 – PROJECT TAILORING

Re-enforcing that all programs and projects must participate in project . As part of the PMM-0102:

Project Management Plan, tailoring should begin during the Initiation and Planning stage, and

updated as needed throughout the project.

pg. 10

UPDATES / CHANGES TO THE PMM AND SUPPORTING DOCUMENTATION

Title 1. DELIVERABLE APPROVAL / ACCEPTANCE Description To provide additional clarification on how approvals will be captured

Impact Assessment Project Management Methodology A - Project Charter: PMM-0101,

• Project Authority: p. 23 B - Project Management Plan: PMM-0102: pp. 25-26 C - Project Closure Report: PMM-0104: pp. 81-84, and top. p 82 Project Closure Report form has been updated to include a signature block

Effective Date January 1, 2020

Update Approach Addendum A – LunchTime Learning Class

A - Project Charter- p. 23

Current Content:

Project authority – Most projects require decisions to be made to keep the project on track. The

project charter defines the authority, limitations or initial checkpoints, of the project manager, the

individual or organization initiating the project, and the oversight (Steering committee) of the

management of the project.

• Approval authority – identifies the project initiator by name and title, ensuring that the

individual has the authority to apply project resources, expend funds, make decisions and give

approvals.

• Project manager – identifies the project manager by name and defines the individual’s level of

authority and limitations …

• Oversight (Steering) committee – describes agency management control over the project ….

Approval information – At a minimum, the agency project sponsor, DTMB project sponsor, and

project manager must sign the project charter.

Content Change: Adding additional paragraphs to approval information

Approval information – At a minimum, the agency project sponsor, DTMB project sponsor, and

project manager must sign the project charter.

Approval signatures of project deliverables will be obtained in one of the following ways:

• Signature on artifact / deliverable

• Electronic signature on artifact / deliverable

• Email approval embedded in / attached to the artifact / deliverable

• Email voting approval embedded in / attached to the artifact / deliverable

• Workflow approval in PPM Tool (when available and support by an audit trail)

If a Customer / Stakeholder name is identified on the deliverable acceptance form, that the

individual must approve by one of the methods identified above. It is the project managers

pg. 11

responsibility to ensure that these approvals are captured. Justifications for deviations must be

documented and are subject to PQA review.

B - Project Management Plan (PMP)

Current Content: pp. 25 - 26

3.2 Project Planning Roles and Responsibilities

Project managers are responsible for developing a project management plan for a specific project.

The project manager is responsible for ensuring that the overall planning requirements are satisfied.

This includes delegating responsibility for specific plan documentation as needed and obtaining

approval signatures.

Content Change: Update 3.2 Project Planning Roles and Responsibilities, adding additional

paragraphs to approval information

Project managers are responsible for developing a project management plan for each project. and

ensuring that the overall planning requirements are satisfies. This includes delegating responsibility

for specific plan documentation as needed and obtaining approval signatures.

Approval signature of project deliverables will be obtained in one of the following ways:




• Email voting approval embedded in / attached to the artifact / deliverable


If a Customer / Stakeholder name is identified on the deliverable acceptance form, then the individual

must approve by one of the methods identified above. It is the project managers responsibility to

ensure that these approvals are captured. Justifications for deviations must be documented and are

subject to PQA review.

C – 6.3 Project Closure Report

Current Content: pp.81 – 84, add to p.82

The project manager reviews the project closure report with the sponsors and obtains their


Content Change: Adding additional paragraph to approval information

The project manager reviews the project closure report with the sponsors and obtains their


Approval signature of project deliverables will be obtained in one of the following ways:




• Email voting approval embedded in / attached the artifact / deliverable

pg. 12


If a Customer / Stakeholder name is identified on the deliverable acceptance form, then the individual

must approve by one of the methods identified above. It is the project managers responsibility to

ensure that these approvals are captured. Justifications for deviations must be documented and are

subject to PQA review.

pg. 13

Title 2. STAGE EXIT SIGN-OFF

Impact Assessment • Project Management Methodology (PMM) 3.11 Quality Management Plan, Acceptance Criteria, pp. 38-43 Add additional section and content “Stage Exit Guidelines”

• PMP-0102: Project Management Plan, add language for Stage Exit

• PMO-0104: Project Closure Report, add language for Stage Exit



PMM Section 3.11, pp. 38 - 43

Current Content:

Acceptance Criteria

The SUITE Systems Engineering Methodology (SEM) provides “stage exits” or points in time, during

the project when the customer and stakeholder will review the deliverables in detail and accept or

reject the work (or accept with noted revisions). Every effort will be made to identify all

stakeholders and plan for their participation in the acceptance process. Each stage of the SEM is

planned, documented, and reviewed by all applicable stakeholders. Each deliverable will be

reviewed and approved, if required, before proceeding to the next stage. Stage exits will be

conducted at the end of each SEM or PMM stage.

Proposed Content: (add additional content to current content)

Stage Exits will be performed for Project Management stage exits as follows:

• Initiation / Planning – Initiation and Planning stage exit approval will be conducted in

conjunction with the PMM:-102: Project Management Plan approval

• Execution – performed, as before, when all project execution tasks have been completed

• Closure – Closure Stage exit approval will be conducted in conjunction with the PMM-0104:

Project Closure Report

Project Managers and Project Teams can combine approval / acceptance as described above or

continue to collect separate deliverables as suited to a given project.

pg. 14

Title 3. STRUCTURED WALKTHROUGH REVIEW AND SIGNOFF

Impact Assessment • Project Management Methodology (PMM) 3.11 Quality Management Plan, Acceptance Criteria, pp. 42-43 Update Table 6 – Structured Walkthrough Guidelines to reflect PMM deliverables

• PMP-0101: Project Charter, add language to reflect that structured walkthrough has occurred in conjunction with deliverable signoff

• PMP-0102: Project Management Plan, add language to reflect that structured walkthrough has occurred in conjunction with deliverable signoff

• PMO-0104: Project Closure Report, add language to reflect that structured walkthrough has occurred in conjunction with deliverable signoff



Section 3.11 Quality Management Plan, pp. 42 - 43

Proposed Content: (add additional content to current content)

Table 6 Structured Walkthrough Guidelines

Work Product Review Type Suggested Reviewers Relevant Documents

PMM-0101: Project Charter*

Always Formal regardless of size / hours

Agency Project Sponsor DTMB Project Sponsor Project Manager Chief Data Steward (Required for Data Intensive Projects)

PMM-0101: Project Charter

PMM-0102: Project Management Plan*


Agency Project Sponsor DTMB Project Sponsor Project Manager Michigan Cyber Security Representative Enterprise Architecture Representative Business Owner Chief Data Steward (Required for Data Intensive Projects)

PMM-0102: Project Management Plan and Tailoring Plan

PMM-0104: Project Closure Report*


Agency Project Sponsor DTMB Project Sponsor Project Manager Chief Data Steward (Required for Data Intensive Projects)

PMM-0104: Project Closure Report

*Project Managers and Project Teams can combine structured walkthrough approvals / acceptances

as described above or continue to collect separate deliverables as suited to a given project.

pg. 15

Title 4. PROJECT CHARTER

Impact Assessment Project Management Methodology (PMM) 2.8 Project Charter, p. 20 Add note indicating that the Approval/Acceptance of the Charter by the sponsors and project manager authorizes the work on the project to begin, under the direction of the project manager.



2.8 Project Charter, p. 20

Current Content:

The first task that the recently assigned project manager must undertake is development of the

project charter. The project charter formally initiates project activities. The charter provides a high-

level description of the project and initial project planning estimates. Distribution of the project

charter marks the end of the initiation phase and serves as the basis for development of the project

management plan.

Content Change: Adding content to indicate that SOW cannot be substituted for a Charter

The first task that a recently assigned project manager must undertake is development of the

project charter. The project charter formally initiates project activities and provides a high-level

description of the project and initial project planning estimates. Approval / Acceptance of the

Charter by the sponsors and the project manager, authorizes the work on the project to begin under

the direction of the project manager.

Note: A Statement of Work (SOW), Service Level Agreement (SLA) or Memorandum of

Understanding (MOU) may not be substituted for a Charter. A project charter needs to be written

to reflect the total scope of work that is required for the project, by both the vendor and the state.

A vendor’s SOW, SLA and / or MOU may be referenced in the project charter to avoid redundancy.

Distribution of the project charter marks the end of the initiation activity and serves as the basis for

development of the project management plan.

pg. 16

Title 5. PROJECT CLOSURE REPORT Budget and Investment Management Sections

Impact Assessment A. Project Management Methodology (PMM) Update 1. Update PMM, 6.3 Project Closure Report, p. 81-84, addition on p. 82 2. Update Clarity with invoice details and cost plans B. PMM-0104: Project Closure Report Update / Editions: Add section 4-Investment Management Performance, which includes the following additional information: ROI baseline at Initiation & Planning, final anticipated ROI baseline at Project Closure, Variance in baselines, and Explanation of Variance



A. 1. PMM, Section 6.3, pp. 81-84, addition on p. 82

Add new section, 4-Investment Management Performance with the following content, and

renumber remaining sections that follow:

Section 4-Investment Management Performance - the project manager should refer to the

enterprise PPM tool to compile information about:

• Return on Investment (ROI), at the Idea and the Initiation & Planning

• Final Anticipated Return on Investment (ROI), at Project Closure

• Return on Investment variances, including difference between initial Return on Investment,

where Variance = ROIInitiation and Planning – ROIProject Closure

• Explanation of Return on Investment (ROI) Variance

2. PMM, Section 6.4, p. 98

Current Content:

Project Account Closure Project account closure is an internal process that formalizes project completion for the project team. It is important for the project manager to set a definitive date for project completion to ensure proper closeout. For example, if a completion date is not set for the project account, it is possible that project personnel could continue to record time and effort to the project. If this were to happen, project cost overruns would occur, and accurate reporting would be compromised.

Proposed Content:

Project Account Closure Add the Project Account Closure note: Note: Project managers must ensure that all project invoices, available as of project close, have

been reviewed and approved by business sponsor. As invoices are reviewed and approved, the

project Cost Plan in the PPM Tool will be updated to reflect approved invoiced project costs. The

project manager is responsible for documenting the party responsible for invoice approvals in the

Closure Report.

pg. 17

B. Add section 4-Investment Management Performance

Content Change: Add new section 4-Investment Management Performance

4-Investment Management Performance

• Initial return on investment (ROI) of the project at Initiation and Planning

• Final Anticipated ROI of the project at Project Closure

• Return on Investment variances, including difference between initial Return on Investment, where Variance = ROIInitiation and Planning – ROIProject Closure

• Explanation of variance

pg. 18

Title 6. PROJECT BUDGET ESTIMATE Impact Assessment Project Management Methodology Update

3.8 Project Budget Estimate, p.33 Update to reflect current project budget estimate processes and add additional language regarding services to consider for estimation.



PMM 3.8 Project Budget Estimate, p. 33

Current Content:

Like other aspects of planning, budget estimating is an iterative process. The initial budget estimate will be revised as requirements are refined and become better understood. In developing an initial high-level budget estimate that is as reliable as possible, it is a best practice for the project manager to search the project repository for similar projects upon which to base this initial estimate. Further guidance on budget estimating is available in the Project Estimating Guide in the appendix. The following tables are consistent with budget data entered in the enterprise PPM tool.

• High Level Budget

FY14 FY15 FY16

Costs (HW, SW, Contractor Deliverables, Client Agency Staff, other)

Services (DTMB Staff & Contractor Staff Augmentation)

Total

Table 3 Project Budget High Level estimate

• Detailed Budget Detailed baseline and actual budget information is entered, updated, monitored and reported through the enterprise PPM tool.

Content Change:

Like other aspects of planning, budget estimating is an iterative process. The project budget

estimate is created by drafting a cost plan in the PPM Tool. Once the cost plan is approved, it

becomes the Cost Plan of Record and is the Project Budget Estimate. In developing an initial high-

level budget estimate that is reliable as possible, it is best practice for the project manager to search

the project repository for similar projects and use the findings to establish this initial estimate. To

the extent known, the project manager will estimate project cost for cost categories as defined in

the PPM Tool by creating line items for cost type(s)/transaction type(s). Further guidance on budget

estimating is available in the Project Estimating Guide in the appendix. The following cost types and

transaction types are consistent with budget data entered in the enterprise PPM tool.

pg. 19

• Detailed Budget Detailed baseline and actual budget information is entered, updated, monitored and reported through the enterprise PPM tool. All known project cost estimates associated with the project, such as: Where Cost Type:

• On-going support cost – IT

• On-going support cost – non-IT

• Project cost – IT

• Project cost – non-IT

Where Transaction Type:

• Administrative

• Agency Staff Labor

• Contingency

• Contract Services

• DTMB Staff Labor

• Hardware

• Hosting / Technical Support

• Other Costs

• Software Licensing

• Storage / Backup

• Training

Note: Include costs associated with new system service or project, such as: ADA Compliance,

Authority to Operate (ATO), MiLogin, PCI Compliance, etc.

The Plan of Record (POR) is the cost plan that is intended to be used as the budget plan for an

investment. If there is an existing approved budget plan, the POR can be used to create a new

budget plan. The first cost plan created for an investment becomes the POR by default.

The Clarity Report, Financial Budget vs. Forecast by Period, can be run and used to provide status

updates to the project stakeholder and team.

Detailed baseline and actual budget information is entered, updated, monitored and reported

through the enterprise PPM tool.

pg. 20

Title 7. RISK MANAGEMENT PLAN

Impact Assessment

PMM Update 3.12 Risk Management Plan, p.43

Effectivity Date January 1, 2020


3.12 Risk Management Plan

Current Content:

The purpose of the risk management plan is to specify the processes used to identify and manage

risk. The risk management plan addresses both internal and external project risks associated with

the project and is drafted prior to completion of the project planning phase. Both the risk,

management plan and the risk log will be regularly reviewed throughout the project to monitor

existing risks and to identify new ones.

The project manager is responsible for facilitating sessions with project stakeholders to identify

risks. A risk owner is assigned to each risk, with responsibility for developing, documenting and

executing risk action plans. The project manager is responsible for monitoring the status of all

project risks and escalating as appropriate.

The enterprise PPM tool supports the risk management process, including the risk log.

Proposed Content: (Include after above section)

pg. 21

Update the PPM Tool, to reflect the risk response strategy as depicted below, including:

• Description

• Impact Description

• Identify the following for risks that are being mitigated:

o Tasks and activities conducted to mitigate risk

o Responsible person assigned to risk management / mitigation tasks

o Target completion dates for risk management / mitigation

• Resolution, with resolved date and item

In this example, the Response Strategy charts the steps needed to mitigate the risk. It identifies what

needs to be done, who needs to do the work and when it will be completed. The Resolution, also

identifies when the risk has been resolved.

This information should be reviewed and updated on a regular basis ranging weekly to monthly

based on the duration of the project and the calculated risk. Risks that have a ‘Calculated Risk’ of

‘RED’ status will be updated on a weekly basis. Project risks must be closed in the PPM Tool when

the risk is no longer a factor. All risks must be closed at project closure.

pg. 22

Title 8. ISSUE MANAGEMENT PLAN

Impact Assessment

PMM Update 3.13 Issue Management Plan, p.48



3.13 Issue Management Plan

Current Content:

The purpose of the issue management plan is to specify the processes used to identify and manage

project issues. The issue management plan addresses both internal and external issues on the

project. The enterprise PPM tool is used to enter, track and report issue activity. Both the issue

management plan and the issue log will be reviewed regularly throughout the project to monitor

existing issues and to identify new ones.

Proposed Content:

The purpose of the issue management plan is to describe the processes used to identify and manage

project issues. The issue management plan addresses both internal and external issues on the

project. The enterprise PPM tool is used to enter, track, and report issue activity.

Update the PPM tool to reflect the Issue Progress and Resolution as depicted below, including:

• Project Issue (Detail Description)

• Progress- Comments will include:

o Remediation steps for alternative and corrective action assignments:

pg. 23

o Tasks and activities

o Responsible person

o Target completion dates

• Resolution with resolved date of issue


based on the duration of the project and the complexity of the issue. Issues with a priority of ‘RED’

will be updated on a weekly basis. Project issues should be closed in the PPM Tool when the issue is

resolved. All issues must be closed at project closure.

pg. 24

Title 9. PROJECT PERFORMANCE MONITORING

Impact Assessment Add new section 5.27 Project Performance Monitoring to:

• Move Project Performance Monitoring content from Section 5.1.5 Schedule Management to this new section

• Update Project Performance Criteria guidance, to reflect current guidelines

• Add tasks and activities to the project schedule (WBS / Gantt Chart) under Monitor & Control – Corrective Action to reflect action steps to get project to ‘green’ status



5.15 Tools and Techniques in Schedule Control

Current Content to be updated and moved to new Section 5.27 Performance Project Monitoring:

The State of Michigan has established criteria for reporting project status, including schedule variance as well as earned value. The following chart depicts “stoplight status” for various performance measures.

pg. 25

New Section and Content:

5.27 Enterprise Project Performance Monitoring & Controlling

Throughout the life cycle of a project, significant amount of data is collected, analyzed and transformed. Project data are collected as a result of various processes and are shared within the project team. The collected data are analyzed in context, aggregated and transformed to become project during various processes.

In support of project status reporting, data will be collected, analyzed and transformed. The State of Michigan has established Enterprise Project Performance Criteria that will be used in determining project status.

Note: For the current version of the Project Performance Criteria, please go to SUITE website >

Forms and Processes, file name: Project Performance Criteria.

One of the primary duties of the Enterprise Portfolio Management Office (EPMO) is to provide

transparency about the status (health of projects in terms of schedule, budget, scope, and risks or

issues which threaten project success. To do this, the State of Michigan (SOM) uses a RED, YELLOW,

GREEN rating system in the enterprise PPM tool to provide senior management with an

understandable snapshot of project status. This color-coding mechanism signals when a project

status is deteriorating and raises it to the attention of the sponsors, business owners and

stakeholders.

• GREEN is the status given to a project that is within budget, timeline, or scope

• YELLOW is the status given when aspects of the project are at risk, and those risks become

issues requiring special attention

• RED is the status given when some aspect of the project has fallen dramatically behind, has

encountered a setback, is over budget, or is outside the expected success parameters

pg. 26

Title 10. CORRECTIVE ACTION PLAN Impact Assessment PMM Update:

Add a Corrective Action Plan section



Corrective Action Plan (CAP) at the end of 5.27 Project Performance Monitoring

When a project is in RED or YELLOW status, the project manager, sponsors and project team must

develop a Corrective Action Plan (CAP) to restore the project to GREEN status. Those with the

authority to make project decisions (generally those with authority to approve project changes and

the Steering Committee) should participate in corrective actions. Instead of approaching this on an

ad-hoc for each project, the state has established a CAP approach to restore the health of sick

projects. The CAP will include:

• The project’s poor health, associated issues and root causes

• The impacts on budget, schedule and scope

• Problem statement(s)

• Alternative and corrective action assignments with recommended remediation steps

o Tasks and activities

o Assigned resources

o Target dates

The assignments should be captured in the enterprise PPM tool- Corrective Action Plan List.


based on the duration of the project and the complexity of the corrective action. Corrective Action

Plans with a priority of ‘HIGH’ will be reviewed on a weekly basis.

pg. 27

Title 11. CHANGE REQUESTS

Impact Assessment

PMM Update: 3.10 Change Management Plan, Table 5 Change Request Steps and Actions, pp. 36-38



3.10 Change Management Plan

Current Content:

Table 5. Change Request Steps and Actions

Step Action Responsibility / Agent

1 Identify and document change request Change Request Initiator

2 Assign Change Request Person Responsible Project Manager

3 Collect and document project impacts, including changes to cost and schedule

Change Request Person Responsible

4 Validate change requests in the Enterprise PPM tool - Project Manager

5 Review change request details for feasibility Project Manager

6 Facilitate CCB review / make decision Project Manager / CCB Members

7 Communicate decision and closure Project Manager

8 Update appropriate schedules and documents Project Manager

9 Update status and close change request

Project Manager

Proposed Content:

Table 5. Change Request Steps and Actions

Step Action Responsibility / Agent

1 Identify and document change request Change Request Initiator

2 Assign Change Request Person Responsible Project Manager

3 Complete the Change Request in the enterprise PPM Tool, by including: Change request description Responsible person Tasks and activities Target completion dates Expected Close Date Impact Assessment Fields: (Currently: Impact of Not Implementing the Change, Change in Cost, Change in Schedule,

Project Manager

pg. 28

Change in Resources, Impact on Baseline, Impact on Other Projects and Impact to Benefit Plan) Note: An attachment to the Change Request in the PPM tool can be added when further detail is needed.

4 Validate change requests in the Enterprise PPM tool - Project Manager

5 Review change request details for feasibility Project Manager

6 Facilitate CCB review / make decision Project Manager / CCB Members

7 Communicate decision and closure Project Manager

8 Draft updates, appropriate schedules and plans (Cost, Budget, Benefits) to reflect pending change, in support of reviewing change request with Project Change Control Board (CCB) Change request status will be reviewed and updated on a regular basis ranging weekly to monthly based on the duration of the project and the complexity of the change request. Ensure that ‘Expected Close Date’ is up-to-date reflecting date change is expected to be implemented. It should not be past due.

Project Manager

9 Upon approval, baseline schedule and create plans of record (Cost, Budget, Benefits), where applicable When required, ensure that the Benefits Plan of Record is referenced in the Cost Plan of Record, so the PPM Tool is calculating the correct Return on Investment (ROI) on the Properties > Financial Summary sheet. Update status and close change request. Once change request has been implemented, ‘work status’ should be changed to ‘closed’.

Project Manager

Note: All project Change Requests must be closed in the PPM tool after the change is

implemented.

pg. 29

Title 12. LESSONS LEARNED Impact Assessment PMM Updates:

A. 2.7 Lessons Learned Review, reinforce current content, p 32 B. 5.3 Impact of Project Monitoring and Controlling, p 73 C. 6.6 Lessons Learned, replace existing section with updated

section



A - 2.7 Lessons Learned

Reinforce Content:

It is an industry best practice to document lessons learned throughout the course of a project, and more importantly, to review lessons learned from similar past projects before embarking on a new project. The project manager should review lessons learned from a project with similar scope prior to beginning work on the project charter. It may be necessary to consult with other project managers to obtain a full understanding of the lessons learned.

B – 5.3 Impact of Project Monitoring and Controlling

Current Content:

A frequently overlooked opportunity that falls under the umbrella of monitoring and controlling is capturing lessons learned as a continuous process rather than as a single event at the conclusion of the project. It is an industry best practice to document lessons learned throughout the course of a project. One way to do this is to use a project journal at each project team meeting. Lessons learned are often the result of monitoring and controlling, and documenting lessons learned as they occur may carry forward throughout the life of the project.

Proposed Content:

A frequently overlooked opportunity that falls under the umbrella of monitoring and controlling, is capturing lessons learned as a continuous process rather than as a single event at the conclusion of the project. Making effective use of Lessons Learned from previous projects and capturing, analyzing, storing and disseminating lessons learned is an integral part of project management. Lessons learned are often the result of monitoring and controlling, and documenting lessons learned as they occur, may carry forward throughout the life of the project.

C – 6.6 Lessons Learned

Current Content:

The purpose of conducting and documenting lessons learned is to help the project team share knowledge gained from experiences that may benefit the entire organization in their future project work. This knowledge includes both positive and negative findings and identifies practices the

pg. 30

organization wants to repeat as well as avoid in the future. The lessons learned are captured within a lessons learned journal on a SUITE form. The lessons learned session is often conducted at the end of the project, at the end of major milestones or project stages, or as a retrospective at the end of each sprint in the Agile world. However, it is considered a best practice to document lessons learned throughout the course of any project. One way to do this is to briefly discuss lessons learned at each team meeting and record them throughout the project in a lessons learned journal. At the end of the project, the project manager invites key stakeholders to a lessons learned meeting. For large and complex projects, it may be necessary to segment stakeholders and convene multiple sessions. If a lessons learned journal was kept throughout the course of the project, it can serve as a focal point for group discussion. The following questions can stimulate discussion: • What areas does the group agree are the biggest success on the project? • What were things that we did very well and want to do the same again on the next project? • What were things that we did well, but could improve, and how? • What were things that we need to improve? • What were the challenges that we encountered during the execution of the project that we

would not want to repeat? • What areas were overlooked on this project? The project manager is responsible for documenting the lessons learned discussion. According to PMBOK, “lessons learned documentation includes the causes of issues, reasoning behind the corrective action chosen, and other types of lessons learned about communications management. Lessons learned need to be documented and distributed so that it becomes part of the historical database for both the project and the performing organization.” Note that lessons learned are summarized in the project closure report. The audience for the project closure report is primarily project sponsors and future project managers, who share an interest in successful project delivery and process improvement. Proposed Content:

Replace the above content with the following:

Learning occurs on every project. Lessons learned is the learning gained from the process of

performing the project. We learn from our own project experiences as well as the experiences of

others. Project managers, team members and leadership can all participate in the lessons learned

sessions, review the lessons learned reports, and make decisions on how to utilize the new acquired

knowledge. Sharing lessons learned across program management offices and within the project

team members, prevents an organization from repetitive mistakes, and allows them to take

advantage of organizational best practices. Innovative approaches and good work practices can be

shared with others, and using Lessons learned should be used to improve stages in current projects

and future projects.

It is not necessary to wait until the end of the project for the learning to occur. Lessons learned can

and should be identified at any point during the project. Lessons learned sessions should be

pg. 31

conducted throughout the lifecycle of the project, based on the criticality and complexity of the

project. Key times are at the end of each phase and in real time – when you learn the lesson.

Waiting to document lessons learned until the end of a project may result in some of the project

lessons not being captured because of lag time in documentation or if team members roll off the

project before the lesson is identified. The lessons learned process consists of the following:

• Capturing lessons learned

o Prepare for lessons learned session – the facilitator will prepare for lessons learned to

ensure that they have some suggested topic areas to discuss

o Conduct lessons learned session – the lessons learned session focuses on identifying

project success and project failures and includes recommendations to improve future

performance on projects. The facilitator should always ask these three key questions:

• What went right?

• What went wrong?

• What needs to be improved?

o Documenting lessons learned – after lessons learned are captured, the lessons learned

will be reviewed with stakeholders by the project manager and at a minimum, they will

be reviewed in conjunction with phase exit reviews

• Analyzing lessons learned – all team members will participate in analyzing and organizing the

lessons learned for application of results, how the team can improve processes, and the team

should improve processes

• Storing lessons learned - the project manager will ensure that lessons learned are stored in the

enterprise PPM tool

• Disseminating Lessons Learned

• Making effective use of lessons learned

o Retrieving lessons learned – the project managers will retrieve lessons learned from the

enterprise PPM Tool when initiating and planning a new project and throughout the

project lifecycle to ensure that teams are learning from the experiences of others.

Specifically, using the enterprise PPM Tool Lessons Learned database, will help identify

potential issues or risks for new projects or in-progress projects.

o Reviewing lessons learned to identify systemic problems – the EPMO will review lessons

learned in the PPM tool to determine if there are systemic problems. They will conduct

root cause analysis, make suggested recommendations for change, and review with

respective governance boards to determine a go forward plan for remediation.

Note that lessons learned are summarized in the project closure report. The audience for the project closure report is primarily project sponsors and future project managers who share an interest in successful project delivery and process improvement.

pg. 32

Title 13. PRODUCT AND QUALITY ASSURANCE (PPQA) PROGRAM / PROJECT QUALITY ASSURANCE (PQA)

Impact Assessment Project Management Methodology 3.11 Quality Assurance Activities, Project Quality Assurance (QA) Reviews All projects are potential subjects for a QA reviews. In addition, PMs will be expected to correct and / or create corrective action plans when non-conformance occurs.



PMM 3.11 Quality Assurance Activities

Current Content:

The DTMB PQA team provides objective project quality reviews to ensure compliance with SUITE

processes, methodologies, and CMMI best practices. The PQA team attempt to review at least one

project per customer agency per year.

Proposed Content Change:

The PQA team provides objective project quality assurance reviews (QA reviews) to ensure

conformance and compliance with SUITE processes, methodologies, and best practices. All projects

are potential subject for a QA reviews as outlined in the PMM. The PQA team will establish,

maintain and communicate clearly stated criteria for evaluations of processes and work products.

QA criteria will be posted on the SUITE QA site.

This will include:

• PMM / SEM Deliverable Compliance

• PPM Tool Compliance

The project managers will be notified of non-compliance found during the evaluation and are

required to correct or create a corrective action plan. Where possible, lessons learned will be

identified and documented by the project manager to ensure that processes are improved for future

products and services.

https://stateofmichigan.sharepoint.com/sites/epmo/suite/SitePages/SUITE%20PPQA.aspx

pg. 33

Title 14. PROJECT TAILORING

Impact Assessment



1.9 Tailoring

Current Content:

Tailoring is the selection of the most appropriate set of standard SUITE processes to satisfy the specific needs of the project. PMM is a component of SUITE and is adaptable to meet the unique requirements of the wide variety of projects the State of Michigan desires to conduct. For projects with a technology component, tailoring the PMM means selecting appropriate SEM components. All tailoring should be described in the Project Management Plan in the section titled Project Approach.

Proposed Content:

Tailoring is the selection of the most appropriate set of standard SUITE processes to satisfy the specific needs of the project. PMM is a component of SUITE and is adaptable to meet the unique requirements of the wide variety of projects the State of Michigan desires to conduct. For projects with a technology component, tailoring the PMM means selecting appropriate SEM components. As a part of the PMM-0102: Project Management Plan, all programs and projects must participate in project tailoring. A tailoring plan must be on file with the EPMO and updated as needed throughout the project.