Berhampur 70918*19311 CALL GIRLS IN ESCORT SERVICE WE ARE PROVIDING
Vonnie simonsen
1. Project Management for Every Size IT Project
Vonnie (Yvonne) Simonsen, PMP
Ames Research Center
Code I Directorate
Project Management Office
Used with Permission
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.
PM Challenge: February 2010 2
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
PM Challenge: February 2010 3
4. 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
$500k and Over: Projects are Under $500k: Projects are
required to follow the NPR 7120.7 required to follow the Code I
project management structure $500K
Project Lifecycle Framework
and over
Under
$500K
PM Challenge: February 2010 4
5. Why a Scaled Project Lifecycle Framework?
Why did we need a scalable Project Framework?
7102.7 IT Project Lifecycle 7120.7 Framework: Project Review
and KDPs
1. System Concept Review (SCR)
2. KDP A – approval to move to Concept
Development Phase
3. Enterprise Architecture Review (EA)
4. Info. /System Security Review
5. Information Assessment
6. System Requirement Review (SRR)
7. KDP B – approval to move to Prelim
Design Phase
8. Preliminary Design Review (PDR)
9. Risk Assessment
10. KDP C – approval to move to Final
Design & Build Phase
• Why not apply the full NPR 7120.7 to ALL 11. Critical Design Review
Projects? 12. KDP D – approval to move to Sys
Assembly Integration & Test Phase
IT teams need to balance NPR 7120.7 with project 13. Certification of Security Controls
14. Security Accreditation Decision
agility and customer requirements. If an IT project
15. Test Readiness Review
has an implementation timeframe of two months, 16. Operational Readiness Review (ORR)
17. KDP E – approval to move to Deploy Ops
does it add value to require ALL projects 16 project & Sustainment Phase
18. Project Completion Review (PCR)
reviews and six KDPs of NPR 7120.7?
19. EA Service Review (EASR)
20. Annual Self-Assessment of Controls
21. KDP F – approval to move to
Decommissioning Phase
22. Decommissioning Review (DR)
PM Challenge: February 2010 5
6. Why a Scaled Project Lifecycle Framework?
Why did we need a scalable Project Framework?
• 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
PM Challenge: February 2010 6
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
PM Challenge: February 2010 7
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.
DIRECTORATE
$500k and Over: Projects are IT PROJECTS
required to follow the NPR 7120.7 Under $500k: No common
project management structure project management structure
$500K
and over
existed within Code I prior to the
Under development of the Lite and
$500K Medium Project Lifecycle
Framework
PM Challenge: February 2010 8
9. 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
PM Challenge: February 2010 9
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
PM Challenge: February 2010 10
11. Overview of the Lite and Medium Project Lifecycle Framework
Lite: Lifecycle Framework
LITE: $ 25K-$99K cost, effects only the Center, significantly impacts Directorate customers
LIFECYCLE PHASES Formulation APPROVAL Implementation
Initiation Acquisition & Development Implementation Operations
Project Lifecycle Pre-Phase A: Phase A: Concept Phase B: Phase C: Final Phase D: System Phase E: Phase F:
Phases Concept Studies Development Preliminary Design Design & Build Assembly Integration Deploy. Ops & Decommissioning
& Test Sustainment
Key Decision
Points (KDPS) KDP-C KDP-E
Project Reviews
System Requirement Preliminary Design Operational.
Review (SRR) Review (PDR) Readiness Review
(ORR)
EA Reviews and
Requirements
IT Security /System
C&A Reviews & Info./ System Security --Certification of Security
Categorization
Requirements Controls
--Security Accred.
Decision
Record Mgmt. &
Privacy Reviews
Available 1. FAD 1. Framework 1. PDR Criteria 1. ORR Criteria
Agreement 2. PDR 2. ORR Presentation •
Templates
2. SRR Criteria Presentation 3. KDP E
3. Info./ System 3. KDP C
Security 4. Baseline Project
Categorization Plan
Instructions 5. Baseline MS
4. SRR Project
Presentation Schedule
5. Project Plan
6. MS Project
Schedule
PM Challenge: February 2010 11
12. Overview of the Lite and Medium Project Lifecycle Framework
Medium: Lifecycle Framework
MEDIUM: $ 100K-$ 499K cost, effects more than one Center, high visibility (Center mgmt., Agency/HQ , and/or other Center’s interest)
LIFECYCLE PHASES Formulation APPROVAL Implementation
Initiation Acquisition & Development Implementation Operations
Project Lifecycle Pre-Phase A: Phase A: Concept Phase B: Phase C: Final Phase D: System Phase E: Phase F:
Phases Concept Studies Development Preliminary Design Design & Build Assembly Integration Deploy. Ops & Decommissioning
& Test Sustainment
Key Decision
Points (KDPS) KDP-C KDP-D KDP-E
Project Reviews
System Requirement Preliminary Design Critical Design Review Operational. Project
Review (SRR) Review (PDR) (CDR) Readiness Review Completion
(ORR) Review (PCR)
Project Management
Review (PMR)
EA Reviews and
Requirements
IT Security /System
Info./ System Security
C&A Reviews & --Certification of Security
Categorization Controls
Requirements
--Security Accred.
Decision
Record Mgmt. &
Privacy Reviews
Available 1. FAD 1. Framework 1. PDR Criteria 1. CDR Criteria 1. ORR Criteria 1. PCR Criteria
Agreement 2. PDR 2. CDR 2. ORR Presentation 2. PCR
Templates
2. SRR Criteria Presentation Presentation 3. KDP E Presentation
3. Info./ System 3. PMR Criteria 3. KDP D
Security 4. PMR
Categorization Presentation
Instructions 5. KDP C
4. SRR 6. Baseline Project
Presentation Plan
5. Project Plan 7. Baseline MS
6. MS Project Project
Schedule Schedule
PM Challenge: February 2010 12
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
PM Challenge: February 2010 13
14. Framework Flexibility
The Framework is flexible and can be tailored
to each project
• 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:
• 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.
PM Challenge: February 2010 14
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
PM Challenge: February 2010 15
16. Project Reviews
REVIEWS
Review Description Lite Medium
Information / System Analysis of the information types to be stored and processed in the system to address three IT
Security security objectives (Confidentiality, Integrity, and Availability). Determines the potential impact
Categorization 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 The SRR examines the functional, technical, performance, and security requirements for the
Requirements system and elements of the preliminary Project Plan and ensures that the requirements and the
Review (SRR) selected concept will satisfy the system objectives.
Preliminary Design The PDR demonstrates that the preliminary design meets all system requirements with
Review (PDR) 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 Purpose of PMR: The PMR demonstrates that the project is managed to the Code I program and
Review (PMR) 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 The CDR confirms that the maturity of the design is appropriate to support proceeding with
Review (CDR) 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.
PM Challenge: February 2010 16
17. Project Reviews (continued)
REVIEWS
Review Description Lite Medium
Security Comprehensive assessment of the management, operational and technical security controls and
Certification 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 Formal declaration by an Authorizing Official that an IT system is compliant with established
Accreditation 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 The ORR determines that the project is ready to go-live with the system or service:
Readiness Review requirements have been met; the functionality, performance, and security controls have been
(ORR) 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 The PCR provides assurance that the implemented system is performing as expected and that all
Review (PCR) 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.
PM Challenge: February 2010 17
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
PM Challenge: February 2010 18
19. Entrance and Success Criteria
• 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.
PM Challenge: February 2010 19
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
PM Challenge: February 2010 20
21. Example of PDR Entrance & Success Criteria:
Preliminary Design Review (PDR) Criteria:
Lite and Medium
NASA LIFECYCLE Formulation APPROVAL Implementation
PHASES
Initiation Acquisition & Development Implementation Operations
Project Lifecycle Pre-Phase A: Phase A: Concept Phase B: Phase C: Final Phase D: System Phase E: Phase F:
Phases Concept Studies Development Preliminary Design Design & Build Assembly Integration Deploy. Ops & Decommissioning
& Test Sustainment
Key Decision
Points (KDPS) KDP-C KDP-D KDP-E
Project Reviews
System Requirement Preliminary Design Critical Design Review Operational. Project
Review (SRR) Review (PDR) (CDR) Readiness Review Completion
(ORR) Review (PCR)
Project Management
Review (PMR)
EA Reviews and
Requirements
IT Security
/System C&A Info./ System Security --Certification of Security
Categorization Controls (completed before
Reviews &
(completed before SRR) ORR)
Requirements
--Security Accred. Decision
(completed before ORR)
Record Mgmt. &
Privacy Reviews
PM Challenge: February 2010 21
22. 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 Yes No
charge to the board have been agreed to by the
technical team, project manager, and review
chair prior to the PDR.
2 Successful completion of the SRR and responses SRR RFAs are closed or a timely closure plan Yes No
has been made to all SRR and Requests for exists for those remaining open.
Action (RFAs), or a timely closure plan exists for
those remaining open
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 Yes No
Schedule baseline, and adequate
documentation exists and/or will exist in a
timely manner to allow proceeding with
development, integration, and test.
PM Challenge: February 2010 22
23. Example of PDR Entrance and Success Criteria:
PDR Entrance and Success Criteria
Preliminary Design Review (PDR)
Entrance Criteria Success Criteria Required? Choose
Yes or No
3B Updated costs Adequate technical and programmatic margins Yes No
and resources exist to complete the
development within budget, schedule, and
risk constraints.
3C Updated Risk assessment and mitigation The project risks are understood, and plans Yes No
and a process and resources exist to
effectively manage them.
3D Preliminary subsystem design specifications for The preliminary design is expected to meet Yes No
each configuration item (hardware and software) the requirements at an acceptable level of
with supporting tradeoff analyses and data, as risk.
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.
PM Challenge: February 2010 23
24. Example of PDR Entrance and Success Criteria:
Optional: Additional PDR Entrance & Success criteria
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, Yes No
including success criteria and any sponsor-imposed
constraints, and ensures that these are finalized,
stated clearly, and are consistent with the prelim.
Design.
4B Updated logistics documentation, as required Adequate logistics processes are in place meeting Yes No
the project’s requirements.
4C Applicable technical plans (e.g., technical Adequate technical margins exist with respect to Yes No
performance measurement plan, reliability performance requirements.
program plan, quality assurance plan)
4D Operational concept The operational concept is technically sound. It Yes No
includes (where appropriate) human factors that
apply, and requirements for its execution flow
down.
PM Challenge: February 2010 24
25. Example of PDR Entrance and Success Criteria:
Optional: Additional PDR Entrance & Success criteria
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 Yes No
requirements.
4F Engineering drawing tree Engineering drawing tree is sound. Yes No
4G Interface control documents Definition of the technical interfaces is consistent with the Yes No
overall technical maturity and provides an acceptable level of
risk.
4H Verification/validation plan The flow down of verifiable requirements is complete and Yes No
proper or, if not, an adequate plan exists for timely resolution
of open items. Requirements are traceable to system goals and
objectives.
4I Plans to respond to regulatory Plan in place to meet project’s requirements regulatory Yes No
requirements (e.g., Section 508), as requirements.
required
4J Requirements traceability matrix The flow down of verifiable requirements is complete and Yes No
proper or, if not, an adequate plan exists for timely resolution
of open items. Requirements are traceable to system goals and
objectives.
4K Disposal plan Plan in place to meet project’s disposal requirements. Yes No
4L Technical resource utilization Adequate technical and programmatic margins and resources Yes No
estimates and margins exist to complete the development within budget, schedule,
and risk constraints.
PM Challenge: February 2010 25
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
PM Challenge: February 2010 26
27. Key Decision Points (KDPs)
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.
PM Challenge: February 2010 27
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
PM Challenge: February 2010 28
29. Who should attend a Review and KDP?
• 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.
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.
PM Challenge: February 2010 29
30. Review and Governing Bodies
Lite: Recommended Governing Body Membership
Lite Classification – Governing Body Membership Recommendation
Review/KDP Recommended Governing Body Membership
System Requirement Review (SRR) Division/Office Representative (Chair)
Customer/Stakeholder Representative
Governance & Policy Representative
System Owner
Info/System Security Categorization Review
Preliminary Design Review (PDR) Division/Office Representative (Chair)
Enterprise Architecture (EA) Representative
ITSM Representative
Technical Peers
System 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 Representative
Division/Office Representative
Governance & Policy Representative
Help Desk Rep (as applicable)
IT Security Representative
Operations Representative
System Owner
KDP E Code I IT PMB
PM Challenge: February 2010 30
31. Review and Governing Body
Medium: Recommended Governing Body Membership
Medium Classification – Governing Body Membership Medium Classification – Governing Body Membership
Recommendations Recommendations (continued)
Review/KDP Recommended Governing Body Review/KDP Recommended Governing Body
Membership Membership
SRR Division/Office Representative (Chair) Certification of Security
CIO Representative Controls & Security
Governance & Policy Representative Accreditation Decision
Customer/Stakeholder Representative ORR CIO Representative (Chair)
Help Desk Representative Customer/Stakeholder
Representative
Info./System
Security Division/Office Rep
Categorization Governance & Policy Rep
Review Help Desk Rep (as applicable)
PDR Division/Office Representative (Chair) IT Security Representative
EA Representative Operations Representative
ITSM Representative System Owner
Technical Peers KDP E Code I IT PMB
PMR PMO Representative (Chair) PCR CIO Rep (Chair)
Budget Management Office Representative Customer/Stakeholder
Representative
KDP C Code I IT PMB
Division/Office Rep
CDR Division/Office Representative (Chair) PMO Representative
Customer/Stakeholder Representative
Enterprise Architecture Representative
Technical Peers
KDP D Code I IT PMB
PM Challenge: February 2010 31
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
PM Challenge: February 2010 32