1. NPR 7120.7 Enhancements and
Agency IT Governance Impacts
Lara Petze
February 10, 2010

2. Agenda
• Background
• NPR 7120.7* Modifications Under
Consideration
–Project baselining and rebaselining
–Standard Level 2 Work Breakdown Structure
(WBS)
–Criteria for projects to be subject to NPR 7120.7
• I-Tools
• Summary
* NPR 7120.7, NASA Information Technology
and Institutional Infrastructure Program and Project
Management Requirements 2

3. Project Project Baselining And Rebaselining
Baselining And Rebaselining
3

4. Background
 NPR 7120.7 identifies four types of IT and
institutional infrastructure investments:
– Information Technology (IT)
– Construction of Facilities (CoF)
– Environmental Compliance and Restoration (ECR)
– Other Mission Support Investments (OMSI)
 This briefing addresses IT investments only
 The updates that we are discussing today are in
draft only, and must be reviewed via the Agency’s
policy approval process
4

5. Background
 NPR 7120.7, Information Technology and Institutional
Infrastructure Program and Project Management
Requirements, was issued in November 2008
 New requirements and Agency experience with using NPR
7120.7 has resulted in the need for modifications in several
significant areas
 OCIO continually identifies candidate changes to NPR 7120.7
to advance the success of the Agency’s IT programs and
projects
5

6. Project Baselining and
Rebaselining Background
 Currently NPR 7120.7 addresses baselining (at Key Decision
Point (KDP)-C) but does not discuss changes to elements of
the baseline that may occur during the project’s
implementation
 As an Agency, we recognize the need to issue policy on
rebaselining of IT projects to manage cost, schedule, and
scope changes
 NASA has accepted Government Accountability Office
(GAO) recommendation that we develop a rebaselining
policy for IT projects
 OMB has issued policy direction (M-10-27) regarding
development of agency IT investment baseline management
policies
6

7. Project Baselining and
Rebaselining Definitions
• Baseline - an agreed-to set of requirements, cost, schedule, designs,
documents, etc. that will have changes controlled through a formal
approval and monitoring process as defined by NPR 7120.7
• Re-baseline - the process by which a project formally updates or
modifies the project baseline as a result of any approved change to
the project’s schedule, cost, or deliverable content
• Re-baseline may result from
1. the baseline documented at KDP-C as defined in NPR 7120.7,
or
2. the current baseline that was subsequently approved via the
rebaselining process.
7

8. NPR 7120.7 IT Project Lifecycle
NASA decides at each KDP whether the project
should move to the next life-cycle phase 8

9. Project Rebaselining Steps
• Determining when a rebaseline is warranted for
consideration
• Developing the proposed new baseline
• Validating the proposed new baseline
• Review and Approval by management of the proposed
new baseline
• Documenting rebaselining decisions
9

10. Determining When a Rebaseline is
Warranted for Consideration: OMB
Direction
 Acceptable reasons for rebaselining include:
» Significant change in investment goals (scope, requirements, objectives)
resulting from internal or external management decisions, or changes in
funding level or availability of funds (e.g. extended continuing resolution), or
contracting (including contractual protests)
» In the case where an incremental or iterative system development and
planning lifecycle has been chosen for the investment, progressive
elaboration may be necessary when transitioning from one iteration or
increment to the next, as scope and objectives evolve. Such rapid evolution
inherent to iterative development shall be approved by the Agency CIO.
» Current baseline is no longer useful as a management tool for realistic
performance measurement as variances are so high that they lose meaning
Issue: how/whether to specify in policy magnitude of
variances that will trigger rebaselining
10

11. Project Rebaselining Thresholds We
Are Considering
 Cost
»If the project’s cost estimate at completion exceeds the
current baseline by 10% or more (is this too low??)
 Schedule
»If the project’s schedule estimate at completion exceeds
the current baseline by 10% or more (is this too
restrictive??)
»If a KDP is forecast to slip by more than 45 days (is this too
restrictive)
Many of our IT projects are of relatively low cost
and of relatively short duration!
11

12. Project Rebaselining Thresholds We
Are Considering
 Scope
» If the project or the customer proposes to add or modify
functional requirements that would result in changes
that exceed the cost and schedule thresholds noted
above, or
» If the project or the customer proposes to defer or
eliminate functional requirements determined by the
customer to be significant, even if the current cost or
schedule baselines are not affected
12

13. Project Rebaselining Thresholds We
Are Considering
 Program Managers
» If a Program Manager imposes more stringent or additional
rebaselining thresholds on a project
» If a Program Manager deems it appropriate to reduce or remove the
thresholds (waiver required)
 Agency IT Program Management Board (PMB)
» If the IT PMB recommends to the NASA CIO thresholds that differ from
those detailed in this document (and the CIO accepts the
recommendation)
The Agency IT PMB is the Governing Body that makes
recommendations to the NASA CIO at each KDP whether a
project should move forward to the next life cycle phase
13

14. Standard Level 2
Work Breakdown Structure
14

15. Standard Level 2
WBS Background
 Work Breakdown Structure (WBS) defined:
(NASA WBS Handbook, January 2010)
– A product-oriented hierarchical division of the hardware, software, services, and other work tasks
that organizes, displays, and defines the products to be developed and/or produced and relates the
elements of the work to be accomplished to each other and the end product(s) . The WBS should
be accompanied by a text document referred to as a WBS Dictionary that describes the work content
each element of the WBS in detail.
 The Standard Level 2 WBS policy will address:
– NASA’s need, as an Agency, for a standard level 2 WBS for IT
– Recommendations from GAO, “GAO Report 10-2; Information Technology; Agencies Need to
Improve the Implementation and use of Earned Value Techniques to Help Manage Major System
Acquisitions; October 2009”
 Good characteristics of a WBS (per GAO, and we agree):
– Applies to the entire life cycle of the project.
– Ensures that changes to the WBS be governed
– Establishes a product-oriented WBS to allow a project to track cost and schedule by defined
deliverables
15

16. Standard Level 2 WBS
For IT Projects: Business Rules
• Project name is WBS Level 1
• Title of each WBS Level 2 element can be modified to facilitate
project-unique titles, but the content of each must remain the same
• Additional WBS elements may be added horizontally as long as the
content does not fit into the content of any existing standard WBS
element
• WBS Level 3 elements, Level 2 subordinate (children), are determined
by the project
• Level 3 and lower elements may differ from project to project and must
include only work that rolls up into the standard WBS Dictionary
definition of the Level 2 element
• An inactive placeholder element (and inactive placeholder financial
code) will be established if no work fits into a standard WBS element
16

17. NPR 7120.5 Level 2 WBS
Space Flight
Projects
WBS
17

18. NPR 7120.8 Level 2 WBS
Research &
Technology
Portfolio Project
WBS
Technology
Development
Project
WBS
18

19. NPR 7120.7 Level 2 WBS*
Information
Technology
Project
WBS
* Courtesy of Kenneth Poole, MSFC
19

20. Standard Level 2 WBS Benefits
 Facilitates planning and control of cost, schedule and technical
content
 Unifies the technical and financial structures of a project
 Enables Project Manager to identify which components are
causing cost and/or schedule overruns and mitigate the root
cause(s) of the overrun
 Eliminates the need for Project Managers to create their own Level
2 WBS
 Enables Earned Value Management for IT projects
 Improves financial reporting/tracking across projects
We are considering extending the standard WBS to level 3
but need more discussion within the Agency before doing so
20

21. Criteria for Projects
to be Subject to NPR 7120.7
21

22. Criteria for Projects to be Subject to
NPR 7120.7
 Current criteria
» New systems/capabilities: $500K or greater total
development and implementation cost or affects more
than one Center
» Modification to or enhancement of existing IT systems
or capabilities: $500K or greater total
modification/enhancement cost, regardless of how
many Centers are affected.
» The NASA/ Center CIO deems that the NPR will apply
(requires consultation with sponsoring organization)
22

23. Criteria for Projects to be Subject to
NPR 7120.7
 Issues with current criteria
» Projects with modest budgets may have trouble meeting all the
NPR requirements without submitting substantial waivers
» Projects with short durations may have trouble accommodating all
the required reviews without submitting substantial waivers
» The Agency and Center IT PMBs (Governing Bodies overseeing
projects) may not have bandwidth to conduct all the required
reviews
 We plan to work with NPR 7120.7 stakeholders to come to
agreement on whether the current criteria should be modified
 One possibility is to create tiers of requirements corresponding to
project size/risk/importance/etc.
23

24. I-Tools
24

25. Summary
 Continual Improvement - the Agency OCIO continually
identifies, solicits, and implements modifications to our
policies to advance the success of the Agency’s IT
programs and projects
 Alignment – the Agency OCIO strives to align IT policies
and procedures with our Human Space Flight (NPR 7120.5)
and Research and Technology (NPR 7120.8)
program/project management policies to maintain
consistency across NASA
25

26. Questions/Discussion?
26