Vonnie simonsen

Project Management for Every Size IT Project
Vonnie (Yvonne) Simonsen, PMP

Ames Research Center
Code I Directorate
Project Management Office

Used with Permission

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


• 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


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


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)


• 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



• Project Reviews


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


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



• Project Reviews


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


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


& 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


• Project Reviews


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.


• Project Reviews


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.


Project Reviews (continued)
REVIEWS
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.



• Project Reviews


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.



• Project Reviews


Example of PDR Entrance & Success Criteria:
Preliminary Design Review (PDR) Criteria:
Lite and Medium
NASA LIFECYCLE Formulation APPROVAL Implementation
PHASES

& 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


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.


PDR Entrance and Success Criteria
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.


Optional: Additional PDR Entrance & Success criteria
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.


Optional: Additional PDR Entrance & Success criteria
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.



• Project Reviews


Key Decision Points (KDPs)
KDPS
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.



• Project Reviews


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.


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)
Division/Office Representative
Governance & Policy Representative
Help Desk Rep (as applicable)
IT Security Representative
Operations Representative
System Owner
KDP E Code I IT PMB


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
Enterprise Architecture Representative
Technical Peers
KDP D Code I IT PMB



• Project Reviews


SATERN On Line Training


Thanks for attending today’s presentation…..

34

Vonnie simonsen

Recommended

Recommended

More Related Content

What's hot

What's hot (20)

Viewers also liked

Viewers also liked (6)

Similar to Vonnie simonsen

Similar to Vonnie simonsen (20)

More from NASAPMC

More from NASAPMC (20)

Recently uploaded

Recently uploaded (20)

Vonnie simonsen