vonnie simonsen

34
Project Management for Every Size IT Project Vonnie (Yvonne) Simonsen, PMP Ames Research Center Code I Directorate Project Management Office Used with Permission

Upload: nasapmc

Post on 18-Dec-2014

11.671 views

Category:

Business


0 download

DESCRIPTION

 

TRANSCRIPT

Page 1: Vonnie simonsen

Project Management for Every Size IT Project

Vonnie (Yvonne) Simonsen, PMP

Ames Research CenterCode I Directorate

Project Management Office

Used with Permission

Page 2: Vonnie simonsen

PM Challenge: February 2010 2

Topic Overview

The NASA Ames Research Center OCIO has developed and implemented a scaled approach (Lite/Medium frameworks) to

Project Management utilizing NPR 7120.7 as the basis.

The Lite and Medium project classifications provide flexibility in managing projects with the added benefit of structure, templates,

and on line training modules.

Page 3: Vonnie simonsen

PM Challenge: February 2010 3

Project Management for Every Size IT Project

• Why a Scalable Framework?

• Scaled Framework Defined

• Overview of Lite and Medium Project Lifecycle

• Framework Flexibility

• Project Reviews

• Entrance and Success Criteria

• Example of PDR Entrance and Success Criteria

• Key Decision Points (KDPs)

• Review and KDP Governing Bodies

• SATERN On Line Training

Page 4: Vonnie simonsen

PM Challenge: February 2010 4

$500k and Over: Projects are required to follow the NPR 7120.7 project management structure $500K

and overUnder $500K

Under $500k: Projects are required to follow the Code I Project Lifecycle Framework

Why a Scaled Project Lifecycle Framework?

Why did we need a scalable Project Framework?PROBLEM

• Project Managers were not provided a common project management framework to follow for

projects below the NPR 7120.7 thresholds. A standardized, consistent, holistic project

management approach did not exist.

• Management did not have an integrated standard view of projects across the Directorate and

associated resource allocation data.

SOLUTION

• Develop and implement a scalable Project Framework that emulates project management best

practices for projects below the NPR 7120.7 threshold.

DIRECTORATE

IT PROJECTS

Page 5: Vonnie simonsen

PM Challenge: February 2010 5

Why a Scaled Project Lifecycle Framework?

Why did we need a scalable Project Framework?

• Why not apply the full NPR 7120.7 to ALL Projects?

IT teams need to balance NPR 7120.7 with project

agility and customer requirements. If an IT project

has an implementation timeframe of two months,

does it add value to require ALL projects 16 project

reviews and six KDPs of NPR 7120.7?

7120.7 Framework: Project Review and KDPs

1. System Concept Review (SCR)2. KDP A – approval to move to Concept

Development Phase3. Enterprise Architecture Review (EA)4. Info. /System Security Review 5. Information Assessment6. System Requirement Review (SRR)7. KDP B – approval to move to Prelim

Design Phase8. Preliminary Design Review (PDR)9. Risk Assessment10. KDP C – approval to move to Final

Design & Build Phase11. Critical Design Review12. KDP D – approval to move to Sys

Assembly Integration & Test Phase13. Certification of Security Controls14. Security Accreditation Decision15. Test Readiness Review16. Operational Readiness Review (ORR)17. KDP E – approval to move to Deploy Ops

& Sustainment Phase18. Project Completion Review (PCR)19. EA Service Review (EASR)20. Annual Self-Assessment of Controls21. KDP F – approval to move to

Decommissioning Phase22. Decommissioning Review (DR)

7102.7 IT Project Lifecycle

Page 6: Vonnie simonsen

PM Challenge: February 2010 6

• Why is the tailored Framework necessary?

• Ensures Projects are following consistent and standard set of implementation

processes and success criteria

• Formulating, approving, implementing, and evaluating

• Disseminating lessons learned

• Aligning NASA’s IT investment and management practices with business

requirements and strategic initiatives

• Two way communication: provide insight and oversight to management as

well as a forum to reach out to Management for assistance

Why a Scaled Project Lifecycle Framework?

Why did we need a scalable Project Framework?

Page 7: Vonnie simonsen

PM Challenge: February 2010 7

Project Management for Every Size IT Project

• Why a Scalable Framework?

• Scaled Framework Defined

• Overview of Lite and Medium Project Lifecycle

• Framework Flexibility

• Project Reviews

• Entrance and Success Criteria

• Example of PDR Entrance and Success Criteria

• Key Decision Points (KDPs)

• Review and KDP Governing Bodies

• SATERN On Line Training

Page 8: Vonnie simonsen

PM Challenge: February 2010 8

Scaled Framework Defined

What is the Scaled Project Lifecycle Framework?

• The Scaled Project Lifecycle Framework:

• Is based on NASA’s NPR 7120.7, that establishes the program and project management requirements for NASA IT programs and projects.

• NASA requires projects follow the NPR 7120.7 if the total development and implementation cost is $500,000 or more and/or the investment affects more than one Center. The NPR 7120.7 does not address projects under the thresholds.

$500k and Over: Projects are required to follow the NPR 7120.7 project management structure $500K

and overUnder $500K

Under $500k: No common project management structure existed within Code I prior to the development of the Lite and Medium Project Lifecycle Framework

DIRECTORATE

IT PROJECTS

Page 9: Vonnie simonsen

PM Challenge: February 2010 99

Scaled Framework Defined

The Scaled Project Framework is segmented into three project classifications: Lite, Medium, and Full

• Lite Project Characteristics

• $ 25K - $ 99K cost AND

• Affects only ARC OR

• Significantly impacts Directorate customers

• Medium Project Characteristics

• $ 100K - $ 499 K cost AND

• Affects more than one Center OR

• High visibility (Center mgmt., Agency/HQ , and/or other Center’s interest)

• Full Project Characteristics

• Greater than $ 500K development & implementation cost OR

• Affects more than one Center

Page 10: Vonnie simonsen

PM Challenge: February 2010 10

Project Management for Every Size IT Project

• Why a Scalable Framework?

• Scaled Framework Defined

• Overview of Lite and Medium Project Lifecycle

• Framework Flexibility

• Project Reviews

• Entrance and Success Criteria

• Example of PDR Entrance and Success Criteria

• Key Decision Points (KDPs)

• Review and KDP Governing Bodies

• SATERN On Line Training

Page 11: Vonnie simonsen

PM Challenge: February 2010 11

LIFECYCLE PHASES Formulation Implementation

Initiation Acquisition & Development Implementation Operations

Project Lifecycle Phases

Pre-Phase A: Concept Studies

Phase A: Concept Development

Phase B: Preliminary Design

Phase C: Final Design & Build

Phase D: System Assembly Integration

& Test

Phase E: Deploy. Ops & Sustainment

Phase F: Decommissioning

Key Decision Points (KDPS)

Project Reviews

EA Reviews and Requirements

IT Security /System C&A Reviews & Requirements

Record Mgmt. & Privacy Reviews

AvailableTemplates

1. FAD 1. Framework Agreement

2. SRR Criteria3. Info./ System

Security Categorization Instructions

4. SRR Presentation

5. Project Plan 6. MS Project

Schedule

1. PDR Criteria2. PDR

Presentation3. KDP C4. Baseline Project

Plan5. Baseline MS

Project Schedule

1. ORR Criteria2. ORR Presentation3. KDP E

APPROVAL

System Requirement Review (SRR)

Info./ System Security Categorization

KDP-C KDP-E

Preliminary Design Review (PDR)

Operational. Readiness Review

(ORR)

--Certification of Security Controls

--Security Accred. Decision

Overview of the Lite and Medium Project Lifecycle Framework

Lite: Lifecycle Framework LITE: $ 25K-$99K cost, effects only the Center, significantly impacts Directorate customers

Page 12: Vonnie simonsen

PM Challenge: February 2010 12

LIFECYCLE PHASES Formulation Implementation

Initiation Acquisition & Development Implementation Operations

Project Lifecycle Phases

Pre-Phase A: Concept Studies

Phase A: Concept Development

Phase B: Preliminary Design

Phase C: Final Design & Build

Phase D: System Assembly Integration

& Test

Phase E: Deploy. Ops & Sustainment

Phase F: Decommissioning

Key Decision Points (KDPS)

Project Reviews

EA Reviews and Requirements

IT Security /System C&A Reviews & Requirements

Record Mgmt. & Privacy Reviews

AvailableTemplates

1. FAD 1. Framework Agreement

2. SRR Criteria3. Info./ System

Security Categorization Instructions

4. SRR Presentation

5. Project Plan 6. MS Project

Schedule

1. PDR Criteria2. PDR

Presentation3. PMR Criteria4. PMR

Presentation5. KDP C6. Baseline Project

Plan7. Baseline MS

Project Schedule

1. CDR Criteria2. CDR

Presentation3. KDP D

1. ORR Criteria2. ORR Presentation3. KDP E

1. PCR Criteria2. PCR

Presentation

APPROVAL

System Requirement Review (SRR)

Info./ System Security Categorization

KDP-C KDP-D KDP-E

Preliminary Design Review (PDR)

Critical Design Review (CDR)

Operational. Readiness Review

(ORR)

Project Completion

Review (PCR)

MEDIUM: $ 100K-$ 499K cost, effects more than one Center, high visibility (Center mgmt., Agency/HQ , and/or other Center’s interest)

Project Management Review (PMR)

--Certification of Security Controls

--Security Accred. Decision

Overview of the Lite and Medium Project Lifecycle Framework

Medium: Lifecycle Framework

Page 13: Vonnie simonsen

PM Challenge: February 2010 13

Project Management for Every Size IT Project

• Why a Scalable Framework?

• Scaled Framework Defined

• Overview of Lite and Medium Project Lifecycle

• Framework Flexibility

• Project Reviews

• Entrance and Success Criteria

• Example of PDR Entrance and Success Criteria

• Key Decision Points (KDPs)

• Review and KDP Governing Bodies

• SATERN On Line Training

Page 14: Vonnie simonsen

PM Challenge: February 2010 14

• Even though the Framework builds discipline into Directorate’s Project Management

capabilities, it is flexible and can be tailored to each project. The Project Manager

determines the appropriate reviews and KDPs.

• The Project Management Office helps project leads determine their project

management approach and provides training/coaching as necessary. This helps

project leads understand what is required and how to get started.

• Each Phase may require project review(s) and a KDP review before the project can

move forward. The reviews and KDPs are called the Project Framework. Depending

on the project, the Project Manager has the option to:

Framework Flexibility

The Framework is flexible and can be tailored to each project

• Present reviews and Key Decision Points (KDPs) together at the same Board meeting. For example;

present SRR, PDR, KDP C together instead of separate meetings with approval from Division/Office

Lead according to the Framework Agreement.

• Add additional reviews (Test Readiness Reviews, additional Security reviews, EA Review, Change Control

reviews, etc.) with approval from Division/Office Lead according to the Framework Agreement.

Additionally, management can add further reviews if necessary.

• Delete unnecessary reviews that do not add value to the project with approval from Division/Office

Lead according to the Framework Agreement.

Page 15: Vonnie simonsen

PM Challenge: February 2010 15

Project Management for Every Size IT Project

• Why a Scalable Framework?

• Scaled Framework Defined

• Overview of Lite and Medium Project Lifecycle

• Framework Flexibility

• Project Reviews

• Entrance and Success Criteria

• Example of PDR Entrance and Success Criteria

• Key Decision Points (KDPs)

• Review and KDP Governing Bodies

• SATERN On Line Training

Page 16: Vonnie simonsen

PM Challenge: February 2010 16

REVIEWS

Review Description Lite Medium

Information / System Security Categorization

Analysis of the information types to be stored and processed in the system to address three IT security objectives (Confidentiality, Integrity, and Availability). Determines the potential impact that a loss would have on the system or functional line of business supported by the information system and the level of IT security required to manage risk to an acceptable level. The result of the analysis is an “IT security category,” validated by an appropriate NASA authority.NOTE: The Information/System Security Categorization Review is different from the other formal reviews required by the Code I Project Lifecycle Framework. The Information/System Security Categorization Review is NOT a formal review or meeting. It is a process that requires all Code I Projects to follow procedures documented in standard operating procedures (SOP). See the Information / System Security Categorization Instructions on the PMO website.

System Requirements Review (SRR)

The SRR examines the functional, technical, performance, and security requirements for the system and elements of the preliminary Project Plan and ensures that the requirements and the selected concept will satisfy the system objectives.

Preliminary Design Review (PDR)

The PDR demonstrates that the preliminary design meets all system requirements with acceptable risk and within the cost and schedule constraints and establishes the basis for proceeding with detailed design. It will show that the correct design option has been selected, interfaces have been identified, and verification methods have been described.

Project Management Review (PMR)

Purpose of PMR: The PMR demonstrates that the project is managed to the Code I program and project management requirements and best practices. The project meets requirements with acceptable risk and within the cost and schedule constraints and establishes the basis for proceeding with the management of detailed design.

Critical Design Review (CDR)

The CDR confirms that the maturity of the design is appropriate to support proceeding with implementation, that it was developed in conjunction with stakeholders, demonstrates that the design meets detailed requirements, and identifies open design issues for the purpose of obtaining a decision to proceed with development and deployment. It reviews the technical architecture to ascertain the effect on the enterprise architecture and reviews the application security design and the inclusion of security controls.

Project Reviews

Page 17: Vonnie simonsen

PM Challenge: February 2010 17

REVIEWS

Review Description Lite Medium

Security Certification

Comprehensive assessment of the management, operational and technical security controls and other safeguards of an IT system. Establishes the extent to which a particular design and implementation meets documented security requirements and any necessary remedial actions. NOTE: This is a continuation of the of the IT Security processes you started in Phase A, Information/System Security Categorization Instructions. Like the Information/System Security Categorization Review, the Security Certification is NOT a formal review or meeting. It is a process that requires all Code I Projects to follow procedures documented in the SOP. You must complete the Security Certification before holding an ORR.

Security Accreditation

Formal declaration by an Authorizing Official that an IT system is compliant with established security requirements, that any residual risks identified during the risk mitigation process are acceptable, and that the system is approved to operate using a prescribed set of safeguards. NOTE: This is a continuation of the of the IT Security processes you started in Phase A, Information/System Security Categorization Instructions. Like the Information/System Security Categorization Review, the Security Accreditation is NOT a formal review or meeting. It is a process that requires all Code I Projects to follow procedures documented in the SOP. You must complete the Security Certification before holding an ORR.

Operational Readiness Review (ORR)

The ORR determines that the project is ready to go-live with the system or service: requirements have been met; the functionality, performance, and security controls have been thoroughly tested; procedures are in place for operations; the users have been adequately trained; and, the organization responsible for operations and sustaining engineering is ready to assume responsibility. It ensures a security plan is in place and that system authorization has been received.

Project Completion Review (PCR)

The PCR provides assurance that the implemented system is performing as expected and that all necessary support requirements are in place and functioning properly. It confirms that the system is operating properly in its production environment. It is the official closeout of the project and project team. The final project schedule is published and remaining open risks are transferred, closed, or accepted. At the conclusion of the PCR, the system is considered fully operational.

Project Reviews (continued)

Page 18: Vonnie simonsen

PM Challenge: February 2010 18

Project Management for Every Size IT Project

• Why a Scalable Framework?

• Scaled Framework Defined

• Overview of Lite and Medium Project Lifecycle

• Framework Flexibility

• Project Reviews

• Entrance and Success Criteria

• Example of PDR Entrance and Success Criteria

• Key Decision Points (KDPs)

• Review and KDP Governing Bodies

• SATERN On Line Training

Page 19: Vonnie simonsen

PM Challenge: February 2010 19

• What are entrance and success criteria for each review?

• The entrance and success criteria are the recommended best practices for technical reviews conducted

as a part of information technology projects. Entrance criteria and success criteria are the minimum

requirements that should be completed before holding a review and the requirements to pass a review.

• At the beginning of each phase, the project will determine the appropriate entrance and success

criteria for the review and send it to the Review Board for review and approval well in advance of the

actual Review.

• How are entrance and success criteria for each review developed?

• The PMO has developed recommended entrance and success criteria for each review based on the NPR

7120.7 but paired down to reflect the Lite and Medium project classifications within the Scaled Project

Lifecycle Framework and formatted it to a user-friendly checklist. The framework allows for additions

or deletions (with justification) to the entrance and success criteria as appropriate due to the unique

nature of each project.

• The entrance and success criteria should reflect the nature of the system under development; be

appropriate for the project’s size, risk, and importance; and be achievable with approved project

resources and on an acceptable schedule.

• The Project Manager and team determine the appropriate entrance and success criteria.

Entrance and Success Criteria

Page 20: Vonnie simonsen

PM Challenge: February 2010 20

Project Management for Every Size IT Project

• Why a Scalable Framework?

• Scaled Framework Defined

• Overview of Lite and Medium Project Lifecycle

• Framework Flexibility

• Project Reviews

• Entrance and Success Criteria

• Example of PDR Entrance and Success Criteria

• Key Decision Points (KDPs)

• Review and KDP Governing Bodies

• SATERN On Line Training

Page 21: Vonnie simonsen

PM Challenge: February 2010 2121

Example of PDR Entrance & Success Criteria:

Preliminary Design Review (PDR) Criteria:Lite and Medium

NASA LIFECYCLE PHASES

Formulation Implementation

Initiation Acquisition & Development Implementation Operations

Project Lifecycle Phases

Pre-Phase A: Concept Studies

Phase A: Concept Development

Phase B: Preliminary Design

Phase C: Final Design & Build

Phase D: System Assembly Integration

& Test

Phase E: Deploy. Ops & Sustainment

Phase F: Decommissioning

Key Decision Points (KDPS)

Project Reviews

EA Reviews and Requirements

IT Security /System C&A Reviews & Requirements

Record Mgmt. & Privacy Reviews

APPROVAL

System Requirement Review (SRR)

Info./ System Security Categorization

(completed before SRR)

--Certification of Security Controls (completed before

ORR)

--Security Accred. Decision (completed before ORR)

KDP-C KDP-D KDP-E

Preliminary Design Review (PDR)

Critical Design Review (CDR)

Operational. Readiness Review

(ORR)

Project Completion

Review (PCR)

Project Management Review (PMR)

Page 22: Vonnie simonsen

PM Challenge: February 2010 2222

Example of PDR Entrance and Success Criteria:

PDR Entrance and Success Criteria Purpose of PDR: The PDR demonstrates that the preliminary design meets all system

requirements with acceptable risk and within the cost and schedule constraints and establishes

the basis for proceeding with detailed design. It will show that the correct design options have

been selected, interfaces have been identified, and verification methods have been described.

Preliminary Design Review (PDR)

Entrance Criteria Success Criteria Required? Choose Yes or No

1 A preliminary PDR agenda, success criteria, and charge to the board have been agreed to by the technical team, project manager, and review chair prior to the PDR.

Yes No

2 Successful completion of the SRR and responses has been made to all SRR and Requests for Action (RFAs), or a timely closure plan exists for those remaining open

SRR RFAs are closed or a timely closure plan exists for those remaining open.

Yes No

3 RECOMMENDED: PDR technical work products listed below for both hardware and software system elements have been made available to the cognizant participants prior to the review:

3A MS Project Schedule High confidence exists in the MS Project Schedule baseline, and adequate documentation exists and/or will exist in a timely manner to allow proceeding with development, integration, and test.

Yes No

Page 23: Vonnie simonsen

PM Challenge: February 2010 2323

Preliminary Design Review (PDR)

Entrance Criteria Success Criteria Required? Choose Yes or No

3B Updated costs Adequate technical and programmatic margins and resources exist to complete the development within budget, schedule, and risk constraints.

Yes No

3C Updated Risk assessment and mitigation The project risks are understood, and plans and a process and resources exist to effectively manage them.

Yes No

3D Preliminary subsystem design specifications for each configuration item (hardware and software) with supporting tradeoff analyses and data, as required. The preliminary software design specification needs to include a completed definition of the software architecture, preliminary database design description, and data conversion plan as applicable.

The preliminary design is expected to meet the requirements at an acceptable level of risk.

Yes No

Example of PDR Entrance and Success Criteria:

PDR Entrance and Success Criteria

Page 24: Vonnie simonsen

PM Challenge: February 2010 2424

Preliminary Design Review (PDR)

Entrance Criteria Success Criteria Required? Choose Yes or No

4 OPTIONAL (due to the unique nature of each project): PDR technical work products listed below for both hardware and software system elements have been made available to the cognizant participants prior to the review:

4A Updated baselined documentation, as required Agreement exists for the top-level requirements, including success criteria and any sponsor-imposed constraints, and ensures that these are finalized, stated clearly, and are consistent with the prelim. Design.

Yes No

4B Updated logistics documentation, as required Adequate logistics processes are in place meeting the project’s requirements.

Yes No

4C Applicable technical plans (e.g., technical performance measurement plan, reliability program plan, quality assurance plan)

Adequate technical margins exist with respect to performance requirements.

Yes No

4D Operational concept The operational concept is technically sound. It includes (where appropriate) human factors that apply, and requirements for its execution flow down.

Yes No

Example of PDR Entrance and Success Criteria:

Optional: Additional PDR Entrance & Success criteria

Page 25: Vonnie simonsen

PM Challenge: February 2010 2525

Preliminary Design Review (PDR)

Entrance Criteria Success Criteria Required? Choose Yes or No

4E Applicable standards Applicable standards are being met per the project’s requirements.

Yes No

4F Engineering drawing tree Engineering drawing tree is sound. Yes No

4G Interface control documents Definition of the technical interfaces is consistent with the overall technical maturity and provides an acceptable level of risk.

Yes No

4H Verification/validation plan The flow down of verifiable requirements is complete and proper or, if not, an adequate plan exists for timely resolution of open items. Requirements are traceable to system goals and objectives.

Yes No

4I Plans to respond to regulatory requirements (e.g., Section 508), as required

Plan in place to meet project’s requirements regulatory requirements.

Yes No

4J Requirements traceability matrix The flow down of verifiable requirements is complete and proper or, if not, an adequate plan exists for timely resolution of open items. Requirements are traceable to system goals and objectives.

Yes No

4K Disposal plan Plan in place to meet project’s disposal requirements. Yes No

4L Technical resource utilization estimates and margins

Adequate technical and programmatic margins and resources exist to complete the development within budget, schedule, and risk constraints.

Yes No

Example of PDR Entrance and Success Criteria:

Optional: Additional PDR Entrance & Success criteria

Page 26: Vonnie simonsen

PM Challenge: February 2010 26

Project Management for Every Size IT Project

• Why a Scalable Framework?

• Scaled Framework Defined

• Overview of Lite and Medium Project Lifecycle

• Framework Flexibility

• Project Reviews

• Entrance and Success Criteria

• Example of PDR Entrance and Success Criteria

• Key Decision Points (KDPs)

• Review and KDP Governing Bodies

• SATERN On Line Training

Page 27: Vonnie simonsen

PM Challenge: February 2010 27

KDPS

Review Description Lite Medium

KDP C - Lite KDP C is a point in time where the Decision Authority makes a decision on the readiness of project to progress to the next phase of the lifecycle, Phase C - Final Design & Build. Projects must have completed or have a solid plan to complete all Requests for Action (RFAs) brought up by the Board during the Information/System Security Categorization, SRR, and PDR

KDP C - Medium KDP C is a point in time where the Decision Authority makes a decision on the readiness of project to progress to the next phase of the lifecycle, Phase C - Final Design & Build. Projects must have completed or have a solid plan to complete all Requests for Action (RFAs) brought up by the Board during the Information/System Security Categorization, SRR, PMR, and PDR.

KDP D – Medium KDP D is a point in time where the Decision Authority makes a decision on the readiness of project to progress to the next phase of the lifecycle, Phase D - System Assembly Integration & Test. Projects must have completed or have a solid plan to complete all Requests for Action (RFAs) brought up by the Board during the CDR.

KDP E KDP E is a point in time where the Decision Authority makes a decision on the readiness of project to “go-live” and progress the next phase of the lifecycle, Phase E – Deployment, Operations, and Sustainment. Projects must have completed or have a solid plan to complete all Requests for Action (RFAs) brought up by the Board during the ORR, Security Accreditation, and Security Certification.

Key Decision Points (KDPs)

Page 28: Vonnie simonsen

PM Challenge: February 2010 28

Project Management for Every Size IT Project

• Why a Scalable Framework?

• Scaled Framework Defined

• Overview of Lite and Medium Project Lifecycle

• Framework Flexibility

• Project Reviews

• Entrance and Success Criteria

• Example of PDR Entrance and Success Criteria

• Key Decision Points (KDPs)

• Review and KDP Governing Bodies

• SATERN On Line Training

Page 29: Vonnie simonsen

PM Challenge: February 2010 29

• Project Manager & Technical Lead:• At a minimum, the Project Manager and Technical Lead present to the Governing Body. Other individuals

involved in the project may be invited, however it is recommended that participants be limited to only those only those who must absolutely attend.

• Reviews Governing Body:• The Governing Body is charted to approve, approve with Requests for Action, or disapprove the review. The

Governing Body membership differs from one project to the next. For example, an infrastructure project may require a different Governing Body membership than a software development project. Project Managers are responsible for working with their management chain (and Project Sponsor, Customer, etc. if necessary) to select the appropriate members for the Governing Body. See the following slide for PMO recommendations on Governing Body membership for each review.

• KDP Decision Authority Governing Body:• The KDP Decision Authority is charted to approve, approve with Requests for Action, or disapprove the

Projects passing to the next Phase of the Project Life cycle. The KDP Governing Body may be either the Directorate IT Project Management Board (IT PMB), the Center IT PMB or the Agency IT PMB depending on the nature of the project and the interest at higher levels.

Who should attend a Review and KDP?

Note: As best practice, projects should not use their reviews as the only communication vehicle to reach out. Projects should be communicating projects status to other interested parties through open forums, all-hand meetings, weekly meeting, emails, newsletters, reports, etc.

Page 30: Vonnie simonsen

PM Challenge: February 2010 30

Lite Classification – Governing Body Membership Recommendation

Review/KDP Recommended Governing Body Membership

System Requirement Review (SRR) Division/Office Representative (Chair)Customer/Stakeholder RepresentativeGovernance & Policy RepresentativeSystem Owner

Info/System Security Categorization Review

Preliminary Design Review (PDR) Division/Office Representative (Chair)Enterprise Architecture (EA) RepresentativeITSM RepresentativeTechnical PeersSystem Owner

KDP C - IT Project Management Board Code I IT PMB

Certification of Security Controls & Security Accreditation Decision

Operational Readiness Review (ORR) CIO Representative (Chair)Customer/Stakeholder RepresentativeDivision/Office Representative Governance & Policy RepresentativeHelp Desk Rep (as applicable)IT Security RepresentativeOperations RepresentativeSystem Owner

KDP E Code I IT PMB

Review and Governing Bodies

Lite: Recommended Governing Body Membership

Page 31: Vonnie simonsen

PM Challenge: February 2010 31

Review and Governing Body

Medium: Recommended Governing Body Membership

Medium Classification – Governing Body Membership Recommendations

Review/KDP Recommended Governing Body Membership

SRR Division/Office Representative (Chair)CIO Representative Governance & Policy RepresentativeCustomer/Stakeholder RepresentativeHelp Desk Representative

Info./System Security Categorization Review

PDR Division/Office Representative (Chair)EA RepresentativeITSM RepresentativeTechnical Peers

PMR PMO Representative (Chair)Budget Management Office Representative

KDP C Code I IT PMB

CDR Division/Office Representative (Chair)Customer/Stakeholder RepresentativeEnterprise Architecture RepresentativeTechnical Peers

KDP D Code I IT PMB

Medium Classification – Governing Body Membership Recommendations (continued)

Review/KDP Recommended Governing Body Membership

Certification of Security Controls & Security Accreditation Decision

ORR CIO Representative (Chair)Customer/Stakeholder

RepresentativeDivision/Office RepGovernance & Policy RepHelp Desk Rep (as applicable)IT Security RepresentativeOperations RepresentativeSystem Owner

KDP E Code I IT PMB

PCR CIO Rep (Chair)Customer/Stakeholder

RepresentativeDivision/Office RepPMO Representative

Page 32: Vonnie simonsen

PM Challenge: February 2010 32

Project Management for Every Size IT Project

• Why a Scalable Framework?

• Scaled Framework Defined

• Overview of Lite and Medium Project Lifecycle

• Framework Flexibility

• Project Reviews

• Entrance and Success Criteria

• Example of PDR Entrance and Success Criteria

• Key Decision Points (KDPs)

• Review and KDP Governing Bodies

• SATERN On Line Training

Page 33: Vonnie simonsen

PM Challenge: February 2010 33

SATERN On Line Training

Page 34: Vonnie simonsen

34

Thanks for attending today’s presentation…..