Search NASA⌕ Search

SEARCH · Search NASA

Results for “Project Management”

Search indexed NASA NTRS and DOE OSTI research on propulsion, heat transfer, battery materials and energy systems. Follow report and document links to the original sources.

Quote a phrase for an exact phrase match. Source license links do not imply unrestricted reuse.

At least 235 records · Page 13

Improving Life-Cycle Cost Management of Spacecraft Missions

This presentation will explore the results of a recent NASA Life-Cycle Cost study and how project managers can use the findings and recommendations to improve planning and coordination early in the formulation cycle and avoid common pitfalls resulting in cost overruns. The typical NASA space science mission will exceed both the initial estimated and the confirmed life-cycle costs by the end of the mission. In a fixed-budget environment, these overruns translate to delays in starting or launching future missions, or in the worst case can lead to cancelled missions. Some of these overruns are due to issues outside the control of the project; others are due to the unpredictable problems (unknown unknowns) that can affect any development project. However, a recent study of life-cycle cost growth by the Discovery and New Frontiers Program Office identified a number of areas that are within the scope of project management to address. The study also found that the majority of the underlying causes for cost overruns are embedded in the project approach during the formulation and early design phases, but the actual impacts typically are not experienced until late in the project life cycle. Thus, project management focus in key areas such as integrated schedule development, management structure and contractor communications processes, heritage and technology assumptions, and operations planning, can be used to validate initial cost assumptions and set in place management processes to avoid the common pitfalls resulting in cost overruns.

Clardy, Dennon↗

Integration of design information

The overall concepts of the integrated programs for aerospace-vehicle design (IPAD) from the user's viewpoint are discussed. Also a top-level view of what the user requires from such a system is provided, and the interactions between the system and user are described. The four major components discussed are design process; data storage, management and manipulation; user interface; and project management. Although an outgrowth of aerospace production experience, the basic concepts discussed, and especially their emphasis on integration, are considered applicable to all problem solving. Thus, these concepts may offer a broad base for exploitation by industry in general. This is the first in a set of three papers, the other two being Future Integrated Design Process, by D. D. Mayer, and Requirements for Company-Wide Management of Engineering Information, by J. W. Southall. In addition to tying the three together, how project management can be handled in a computing environment and also the user interface needs are discussed in detail.

Anderton, G. L.↗

NASA Schedule Management Handbook

The purpose of schedule management is to provide the framework for time-phasing, resource planning, coordination, and communicating the necessary tasks within a work effort. The intent is to improve schedule management by providing recommended concepts, processes, and techniques used within the Agency and private industry. The intended function of this handbook is two-fold: first, to provide guidance for meeting the scheduling requirements contained in NPR 7120.5, NASA Space Flight Program and Project Management Requirements, NPR 7120.7, NASA Information Technology and Institutional Infrastructure Program and Project Requirements, NPR 7120.8, NASA Research and Technology Program and Project Management Requirements, and NPD 1000.5, Policy for NASA Acquisition. The second function is to describe the schedule management approach and the recommended best practices for carrying out this project control function. With regards to the above project management requirements documents, it should be noted that those space flight projects previously established and approved under the guidance of prior versions of NPR 7120.5 will continue to comply with those requirements until project completion has been achieved. This handbook will be updated as needed, to enhance efficient and effective schedule management across the Agency. It is acknowledged that most, if not all, external organizations participating in NASA programs/projects will have their own internal schedule management documents. Issues that arise from conflicting schedule guidance will be resolved on a case by case basis as contracts and partnering relationships are established. It is also acknowledged and understood that all projects are not the same and may require different levels of schedule visibility, scrutiny and control. Project type, value, and complexity are factors that typically dictate which schedule management practices should be employed.

Source record↗

Habitat Demonstration Unit Project: Leadership and Management Strategies for a Rapid Prototyping Project

This paper gives an overview of the National Aeronautics and Space Administration (NASA) led multi-center Habitat Demonstration Unit (HDU) project leadership and management strategies being used by the NASA HDU team for a rapid prototyping project. The HDU project team constructed and tested an analog prototype lunar surface habitat/laboratory called the Pressurized Excursion Module (PEM) during 2010. The prototype unit subsystems were integrated in a short amount of time, utilizing a tiger team rapid prototyping approach that brought together over 20 habitation-related technologies and innovations from a variety of NASA centers. This paper describes the leadership and management strategies as well as lessons learned pertaining to leading and managing a multi-center diverse team in a rapid prototype environment. The PEM configuration went from a paper design to an operational surface habitat demonstration unit in less than 12 months. The HDU project is part of the strategic plan from the Exploration Systems Mission Directorate (ESMD) Directorate Integration Office (DIO) and the Exploration Mission Systems Office (EMSO) to test destination elements in analog environments. The 2011 HDU-Deep Space Habitat (DSH) configuration will build upon the PEM work, and emphasize validity of crew operations (remote working and living), EVA operations, mission operations, logistics operations, and science operations that might be required in a deep space context for Near Earth Object (NEO) exploration mission architectures. The 2011 HDU-DSH will be field-tested during the 2011 Desert Research and Technologies Studies (DRaTS) field tests. The HDU project is a "technology-pull" project that integrates technologies and innovations from multiple NASA centers. This project will repurpose the HDU 2010 demo unit that was field tested in the 2010 DRaTS, adding habitation functionality to the prototype unit. This paper will describe the strategy of establishing a multi-center project management team that put in place the key multi-center leadership skills and disciplines to enable a successful tiger team approach. Advocacy was established with key stakeholders and NASA Headquarters (HQ) by defining a strategic vision, mission, goals and objectives for the project and team. As a technology-pull testbed capability the HDU project was able to collaborate and leverage the Exploration Technology Development Program (ETDP) and individual NASA center investments which capitalized on their respective center core competencies and skills. This approach enable the leveraging of over $7.5m of value to create an operational habitat demonstration unit 2010 PEM configuration.

Kennedy, Kriss J.↗

Software Formal Inspections Guidebook

The Software Formal Inspections Guidebook is designed to support the inspection process of software developed by and for NASA. This document provides information on how to implement a recommended and proven method for conducting formal inspections of NASA software. This Guidebook is a companion document to NASA Standard 2202-93, Software Formal Inspections Standard, approved April 1993, which provides the rules, procedures, and specific requirements for conducting software formal inspections. Application of the Formal Inspections Standard is optional to NASA program or project management. In cases where program or project management decide to use the formal inspections method, this Guidebook provides additional information on how to establish and implement the process. The goal of the formal inspections process as documented in the above-mentioned Standard and this Guidebook is to provide a framework and model for an inspection process that will enable the detection and elimination of defects as early as possible in the software life cycle. An ancillary aspect of the formal inspection process incorporates the collection and analysis of inspection data to effect continual improvement in the inspection process and the quality of the software subjected to the process.

Source record↗

An Approach to Tailoring Major Technical Reviews Based on Project Characteristics and Stakeholder Interests

There are numerous technical reviews that occur throughout the systems engineering process life cycle. Many are well known by project managers and stakeholders such as developers and end users, an example of much is the critical design review (CDR). This major milestone for a large, complex new project may last two or more days, include an extensive agenda of topics, and entail hundreds of hours of developer time to prepare presentation materials and associated documents. Additionally, the weeks of schedule spent on review preparation is at least partly at the expense of other work. This paper suggests an approach for tailoring technical reviews, based on the project characteristics and the project manager s identification of the key stakeholders and understanding of their most important issues and considerations. With this insight the project manager can communicate to, manage expectations oc and establish formal agreement with the stakeholders as to which reviews, and at what depth, are most appropriate to achieve project success. The authors, coming from diverse organizations and backgrounds, have drawn on their personal experiences and summarized the best practices of their own organizations to create a common framework to provide guidance on the adaptation of design reviews to other system engineers.

Richstein, Alan B.↗

Software management tools: Lessons learned from use

Experience in inserting software project planning tools into more than 100 projects producing mission critical software are discussed. The problems the software project manager faces are listed along with methods and tools available to handle them. Experience is reported with the Project Manager's Workstation (PMW) and the SoftCost-R cost estimating package. Finally, the results of a survey, which looked at what could be done in the future to overcome the problems experienced and build a set of truly useful tools, are presented.

Reifer, D. J.↗

Oh, Develop

In a mature view of the subject, career development is not simply four years of college or a week at training, culminating in a diploma or a certificate to hang on an office wall. That's why we wanted to take a broad look at career development in this issue of ASK. Take for example, Dr. Gerald Mulenburg s contribution, Fly on the Wall. When Mulenburg and other members of a knowledge-sharing group at Ames were invited to observe an upcoming project review, Mulenburg thought it would be interesting to learn how another project does its reviews. Note that Mulenburg is no fresh out who's never attended a NASA project review. Not only has he been through a fair share of them as the reviewed, he has also been on the other side of the table as a reviewer. This experienced project manager recognizes that at any stage of a career there is room to grow and develop one's repertoire. Too often people associate career development with textbooks and role classroom training, far removed from project life. But classroom training need not be like this, as you'll find in our Special Feature, The Enterprise Project by Wendy Dolci, which sprung out of an APPL Advanced Project Management class in July 2003 at Ames Research Center. In addition to Dolci, some of her classmates contribute to the story. Mike Sander of the Jet Propulsion Laboratory, project manager for the Mars Science Laboratory mission, who provided the assignment on which the story is based, also has a cameo in the story. We think Dolci's story is an inspiring example of what classroom training can be if it's approached imaginatively and made to serve a practical purpose. Another story from Ames, by Frank Larsen, takes a different twist on career development. At the annual Experimental Aircraft Association Fly-in in Oshkosh, Wisconsin, Larsen represented Ames at a NASA booth. While there, Larsen met a colleague from Glenn Research Center. Months later on a project with a quick turnaround, he remembered his colleague from Glenn who had equipment that might help Larsen save time and money on his project. Although they had never worked together and they had to unravel a lot of red tape before they could collaborate, they managed a way to get the job done. There are other stories in this issue that deal directly with this theme of career development. Then there are others in which it is less explicit. But if you take the view that career development happens all the time, and is as necessary to your survival as breathing, then you can read almost any story in ASK with your career development in mind. In that case, all the best, and so then-start developing.

Post, Todd↗

Project Interface Requirements Process Including Shuttle Lessons Learned

Most failures occur at interfaces between organizations and hardware. Processing interface requirements at the start of a project life cycle will reduce the likelihood of costly interface changes/failures later. This can be done by adding Interface Control Documents (ICDs) to the Project top level drawing tree, providing technical direction to the Projects for interface requirements, and by funding the interface requirements function directly from the Project Manager's office. The interface requirements function within the Project Systems Engineering and Integration (SE&I) Office would work in-line with the project element design engineers early in the life cycle to enhance communications and negotiate technical issues between the elements. This function would work as the technical arm of the Project Manager to help ensure that the Project cost, schedule, and risk objectives can be met during the Life Cycle. Some ICD Lessons Learned during the Space Shuttle Program (SSP) Life Cycle will include the use of hardware interface photos in the ICD, progressive life cycle design certification by analysis, test, & operations experience, assigning interface design engineers to Element Interface (EI) and Project technical panels, and linking interface design drawings with project build drawings

Bauch, Garland T.↗

Continuous Risk Management: A NASA Program Initiative

NPG 7120.5A, "NASA Program and Project Management Processes and Requirements" enacted in April, 1998, requires that "The program or project manager shall apply risk management principles..." The Software Assurance Technology Center (SATC) at NASA GSFC has been tasked with the responsibility for developing and teaching a systems level course for risk management that provides information on how to comply with this edict. The course was developed in conjunction with the Software Engineering Institute at Carnegie Mellon University, then tailored to the NASA systems community. This presentation will briefly discuss the six functions for risk management: (1) Identify the risks in a specific format; (2) Analyze the risk probability, impact/severity, and timeframe; (3) Plan the approach; (4) Track the risk through data compilation and analysis; (5) Control and monitor the risk; (6) Communicate and document the process and decisions.

Hammer, Theodore F.↗

Tipping the Balance

As an activist for the project community at NASA's Ames Research Center, I see my role as finding out what resource project managers need to help them run successful projects. I need to go out and advocate for those resources, if necessary, and I need to be supportive, not just for the projects, but also for the project managers and their teams. It's not something I can do sitting at my desk waiting for the phone to ring. To me, that's what an activist does. It's public service. In this case my public is the project-practitioner community.

Smith, Claire↗

Customer Responsiveness

If you know anyone who's been involved in building a spacecraft, I'm sure you've heard the mantra, 'Test what you fly, and fly what you test.' Listen to a project manager from my institution (The Johns Hopkins Applied Physics Laboratory, a.k.a. APL) talking in his or her sleep, and this is likely what you're going to hear. At APL, we do a lot of testing. We probably do more testing in the initial stages of a project than we could explain to review boards. Perhaps we are conservative in this respect, but our project managers and engineers believe in getting a good night's sleep before a launch, and testing is a good way of ensuring that. So you can imagine my reaction when the NASA project manager, Don Margolies, suggested that on the Advanced Composition Explorer (ACE) mission we pull all the instruments off the spacecraft after we had just completed the full range of environmental testing. This would allow the scientists to do a better job of calibrating their instruments.

Chiu, Mary↗

Institutionalizing Lessons Learned

The NASA Integrated Action Team (NIAT) was formed by the NASA Administrator in March 2000. The purpose of this team was to identify the actions that NASA must take to address systemic findings reported in 4 different anomaly investigations. Team membership represented senior managers from all the field centers and NASA Headquarters. NIAT report addressed 165 findings and developed 17 action plans that are described in five themes: people and teams, technology, risk, formulation rigor, and communications. The NIAT actions present a systems solution for strengthening formulation and implementation of programs and improving the environment for their support. NIAT results included: enhancing success by avoiding failures that could have been prevented through good planning and sound practice; ensuring that prudent risks do not compromise safety; and ensuring that mission risks are objectively assessed, appropriately mitigated and consciously accepted by the program team and customers. Definitions of Faster, Better, Cheaper and Success Criteria were also developed and included as part of the NIAT report. As a result of the NIAT report, program and project management process changes were incorporated into NASA's quality system documentation, including NPG 7120.513, "NASA Program and Project Management Processes and Requirements. This paper describes the NIAT results and the resulting updates to NPG 7120.5 that keep this program and project management description a living process.

McBrayer, Robert O.↗

When My Name Suddenly Was "Murphy"

The author recounts how he was named the Launch Vehicle Manager for the Mars Pathfinder mission, after his project manager suffered a heart attack shortly before launch. He explains that he was prepared for the sudden responsibilities, since his project manager required that he learn many new skills.

Mitchell, David↗

Extension of MBSE for Project Programmatics Management on the Asteroid Redirect Robotic Mission

Model-based Systems Engineering can be employed beyond management of the technical architecture development of a system to also manage the programmatics associated with Systems Engineering activities of a project. On NASA’s Asteroid Redirect Robotic Mission, MBSE has been successfully employed to manage, generate, and interact with the documentation-based deliverables associated with System Engineering activities. This has been involved in defining and tracking project document, milestone, and personnel metadata via the same modeling framework used for the technical architecture management. Additionally, it has focused on improving overall user experiences through linkage of documentation to technical content in the system model, automation of manually intensive tasks, and others stakeholderoriented features.

Mozafari, Tanaz↗

America's Next Great Ship: Space Launch System Core Stage Transitioning from Design to Manufacturing

The Space Launch System (SLS) Program is essential to achieving the Nation's and NASA's goal of human exploration and scientific investigation of the solar system. As a multi-element program with emphasis on safety, affordability, and sustainability, SLS is becoming America's next great ship of exploration. The SLS Core Stage includes avionics, main propulsion system, pressure vessels, thrust vector control, and structures. Boeing manufactures and assembles the SLS core stage at the Michoud Assembly Facility (MAF) in New Orleans, LA, a historical production center for Saturn V and Space Shuttle programs. As the transition from design to manufacturing progresses, the importance of a well-executed manufacturing, assembly, and operation (MA&O) plan is crucial to meeting performance objectives. Boeing employs classic techniques such as critical path analysis and facility requirements definition as well as innovative approaches such as Constraint Based Scheduling (CBS) and Cirtical Chain Project Management (CCPM) theory to provide a comprehensive suite of project management tools to manage the health of the baseline plan on both a macro (overall project) and micro level (factory areas). These tools coordinate data from multiple business systems and provide a robust network to support Material & Capacity Requirements Planning (MRP/CRP) and priorities. Coupled with these tools and a highly skilled workforce, Boeing is orchestrating the parallel buildup of five major sub assemblies throughout the factory. Boeing and NASA are transforming MAF to host state of the art processes, equipment and tooling, the most prominent of which is the Vertical Assembly Center (VAC), the largest weld tool in the world. In concert, a global supply chain is delivering a range of structural elements and component parts necessary to enable an on-time delivery of the integrated Core Stage. SLS is on plan to launch humanity into the next phase of space exploration.

Birkenstock, Benjamin↗

Earned Value Management (EVM): Reference Guide for Project-Control Account Managers

The purpose of this guide is intended to be a quick reference for a Project-Control Account Manager (P CAM) or technical manager empowered with a project’s cost, schedule, and technical responsibilities of a control account(s) when Earned Value Management (EVM) is required. The overall objective is to support the P CAM in performing their responsibilities as they relate to EVM. In addition, the reference guide describes at a summary level how the scope, schedule, and budget of a project integrate for optimal planning and control of prime contracts and in-house projects.

Control Account Manager↗

Managing the Development of the Wide-Field Infrared Survey Explorer Mission

The Wide-field Infrared Survey Explorer (WISE), a NASA Medium-Class Explorer (MIDEX) mission, is surveying the entire sky in four bands from 3.4 to 22 microns with a sensitivity hundreds to hundreds of thousands times better than previous all-sky surveys at these wavelengths. The single WISE instrument consists of a 40 cm three-mirror anastigmatic telescope, a two-stage solid hydrogen cryostat, a scan mirror mechanism, and reimaging optics giving 6" resolution (full-width-half-maximum). WISE was placed into a Sun-synchronous polar orbit on a Delta II 7320 launch vehicle on December 14, 2009. NASA selected WISE as a MIDEX in 2002 following a rigorous competitive selection process. To gain further confidence in WISE, NASA extended the development period one year with an option to cancel the mission if certain criteria were not met. MIDEX missions are led by the principal investigator who in this case delegated day-to-day management to the project manager. With a cost cap and relatively short development schedule, it was essential for all WISE partners to work seamlessly together. This was accomplished with an integrated management team representing all key partners and disciplines. The project was developed on budget and on schedule in spite of the need to surmount significant technical challenges. This paper describes our management approach, key challenges and critical decisions made. Results are described from a programmatic, technical and scientific point of view. Lessons learned are offered for projects of this type.

cryogenic↗