Project Management Methodology - Addendum A (as of 12/05/19€¦ · • PMM-0102: Project...
Transcript of Project Management Methodology - Addendum A (as of 12/05/19€¦ · • PMM-0102: Project...
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
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:
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.
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
• Responsible person
• Tasks, activities
• Target completion dates
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
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:
• Responsible person
• Corrective actions
• Target completion dates
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:
• 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, 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
approval signatures.
Content Change: Adding additional paragraph to approval information
The project manager reviews the project closure report with the sponsors and obtains their
approval signatures.
Approval signature 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 the artifact / deliverable
pg. 12
• 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, 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
Effective Date January 1, 2020
Update Approach Addendum A – LunchTime Learning Class
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
Effective Date January 1, 2020
Update Approach Addendum A – LunchTime Learning Class
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*
Always Formal regardless of size / hours
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*
Always Formal regardless of size / hours
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.
Effective Date January 1, 2020
Update Approach Addendum A – LunchTime Learning Class
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
Effective Date January 1, 2020
Update Approach Addendum A – LunchTime Learning Class
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.
Effective Date January 1, 2020
Update Approach Addendum A – LunchTime Learning Class
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
Update Approach Addendum A – LunchTime Learning Class
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
Effectivity Date January 1, 2020
Update Approach Addendum A – LunchTime Learning Class
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
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 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
Effectivity Date January 1, 2020
Update Approach Addendum A – LunchTime Learning Class
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
Effectivity Date January 1, 2020
Update Approach Addendum A – LunchTime Learning Class
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.
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. 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
Effectivity Date January 1, 2020
Update Approach Addendum A – LunchTime Learning Class
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
Effectivity Date January 1, 2020
Update Approach Addendum A – LunchTime Learning Class
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.
Effective Date January 1, 2020
Update Approach Addendum A – LunchTime Learning Class
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.
pg. 33
Title 14. PROJECT TAILORING
Impact Assessment
Effective Date January 1, 2020
Update Approach Addendum A – LunchTime Learning Class
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.