The document provides an integrated master schedule (IMS) for the Ares I-X flight test. It lists the IMS manager and project integration manager. The IMS details activities for various elements from 2008 to 2009, including delivery dates for components to the assembly facility and timelines for assembly, integration testing, and launch. The overall schedule aims to provide 60 days of margin and reduce rework through integrated planning.
This document summarizes key points from a paper on how complex systems fail. It discusses that complex systems are inherently hazardous due to multiple potential failure points, but have many defensive layers that generally prevent failures. It notes that catastrophes occur when small, disconnected failures combine in unexpected ways. Complex systems also constantly operate with some degraded functionality and latent failures, requiring operators to adapt over time to changing conditions in order to maintain safety.
This document discusses using the National Advisory Committee for Aeronautics (NACA) approach to stimulate commercial spaceflight capabilities and achieve low-cost access to space. The NACA successfully built a world-leading aeronautics industry in the US in the early 20th century by partnering with government agencies and industry, conducting broad research, and openly publishing results without picking specific winners. The document argues NASA could adopt this approach of building an entire commercial space industry through partnerships and by addressing priority technical needs, rather than centrally-planning programs to pick winners. This may help achieve the Obama Administration's goal of stimulating commercial spaceflight where previous large, centrally-planned programs have failed.
This document discusses the importance of strengthening the connection between technical and financial managers on projects. Traditionally, these managers operate independently with the technical manager focused on requirements and the financial manager on funding. However, this can lead to problems like cost overruns, missed deadlines, and inconsistent information. To overcome these issues, the document recommends that the managers improve communication, develop a trusting relationship, work together on reviews, and share basic knowledge so technical changes are assessed for their budget impacts and funding issues are addressed jointly. Regular communication and cooperation between these critical roles is needed for a project's success.
The document summarizes the goals and approach of the Software Architecture Review Board (SARB). The SARB aims to help NASA missions achieve higher reliability and cost savings by managing flight software complexity through better software architecture. It will do this by engaging with flight projects in the early stages of software architecture development to provide constructive feedback. The board will also help spread best practices across NASA and contribute to lessons learned. The summary discusses the typical architecture review process used, including preparation, meetings, and follow-up reports. It also outlines common issues identified in reviews and perceived impediments to software architecture at NASA.
This document discusses integrated predictive performance management as a method for effective project management. It involves developing an integrated baseline for technical scope, schedule, and budget that serves as a shared plan. Performance is measured by comparing work completed to the baseline. This allows for predicting future performance and taking early actions to positively impact outcomes. Benefits include integrated performance measurement, a disciplined planning methodology, and improved visibility, accountability, and risk management. The key is for projects to own their baselines which are then status reported and maintained through a change control process.
This document discusses trends in project management (PM) and systems engineering (SE) costs for NASA space missions. It finds that PM and SE costs have been increasing over time as a percentage of total mission costs, driven by factors like increasing technical complexity, scale of projects, and specialization. Data is presented showing trends in PM and SE costs for NASA-funded APL space missions and other NASA robotic missions from 1996-2018. While instrument management costs have declined for some missions since 2002, overall the data indicates PM and SE costs are growing and additional resources are needed to ensure project success in the current environment.
This document summarizes a presentation about lessons learned from NASA's Stardust comet sample return mission. The Stardust mission returned the first solid samples from a comet in 2006. Key lessons included the value of detailed pre-flight measurements and instrumentation that were not included due to budget and schedule constraints. Future missions could benefit from more proactive "planning for learning" approaches rather than just reactive "lessons learned." Careful recovery operations are also important for preserving samples and data about the heatshield's condition upon reentry.
The document discusses the development of requirements for a vehicle through model-based systems engineering. It provides examples of models that can be used to capture a vehicle's operational concept, including a design reference mission diagram, a phase model, and an activity model. The models aim to depict how the vehicle and crew interact during different mission activities and phases to achieve objectives. They are used to identify vehicle capabilities and functions needed to implement the operational concept.
This document summarizes key points from a paper on how complex systems fail. It discusses that complex systems are inherently hazardous due to multiple potential failure points, but have many defensive layers that generally prevent failures. It notes that catastrophes occur when small, disconnected failures combine in unexpected ways. Complex systems also constantly operate with some degraded functionality and latent failures, requiring operators to adapt over time to changing conditions in order to maintain safety.
This document discusses using the National Advisory Committee for Aeronautics (NACA) approach to stimulate commercial spaceflight capabilities and achieve low-cost access to space. The NACA successfully built a world-leading aeronautics industry in the US in the early 20th century by partnering with government agencies and industry, conducting broad research, and openly publishing results without picking specific winners. The document argues NASA could adopt this approach of building an entire commercial space industry through partnerships and by addressing priority technical needs, rather than centrally-planning programs to pick winners. This may help achieve the Obama Administration's goal of stimulating commercial spaceflight where previous large, centrally-planned programs have failed.
This document discusses the importance of strengthening the connection between technical and financial managers on projects. Traditionally, these managers operate independently with the technical manager focused on requirements and the financial manager on funding. However, this can lead to problems like cost overruns, missed deadlines, and inconsistent information. To overcome these issues, the document recommends that the managers improve communication, develop a trusting relationship, work together on reviews, and share basic knowledge so technical changes are assessed for their budget impacts and funding issues are addressed jointly. Regular communication and cooperation between these critical roles is needed for a project's success.
The document summarizes the goals and approach of the Software Architecture Review Board (SARB). The SARB aims to help NASA missions achieve higher reliability and cost savings by managing flight software complexity through better software architecture. It will do this by engaging with flight projects in the early stages of software architecture development to provide constructive feedback. The board will also help spread best practices across NASA and contribute to lessons learned. The summary discusses the typical architecture review process used, including preparation, meetings, and follow-up reports. It also outlines common issues identified in reviews and perceived impediments to software architecture at NASA.
This document discusses integrated predictive performance management as a method for effective project management. It involves developing an integrated baseline for technical scope, schedule, and budget that serves as a shared plan. Performance is measured by comparing work completed to the baseline. This allows for predicting future performance and taking early actions to positively impact outcomes. Benefits include integrated performance measurement, a disciplined planning methodology, and improved visibility, accountability, and risk management. The key is for projects to own their baselines which are then status reported and maintained through a change control process.
This document discusses trends in project management (PM) and systems engineering (SE) costs for NASA space missions. It finds that PM and SE costs have been increasing over time as a percentage of total mission costs, driven by factors like increasing technical complexity, scale of projects, and specialization. Data is presented showing trends in PM and SE costs for NASA-funded APL space missions and other NASA robotic missions from 1996-2018. While instrument management costs have declined for some missions since 2002, overall the data indicates PM and SE costs are growing and additional resources are needed to ensure project success in the current environment.
This document summarizes a presentation about lessons learned from NASA's Stardust comet sample return mission. The Stardust mission returned the first solid samples from a comet in 2006. Key lessons included the value of detailed pre-flight measurements and instrumentation that were not included due to budget and schedule constraints. Future missions could benefit from more proactive "planning for learning" approaches rather than just reactive "lessons learned." Careful recovery operations are also important for preserving samples and data about the heatshield's condition upon reentry.
The document discusses the development of requirements for a vehicle through model-based systems engineering. It provides examples of models that can be used to capture a vehicle's operational concept, including a design reference mission diagram, a phase model, and an activity model. The models aim to depict how the vehicle and crew interact during different mission activities and phases to achieve objectives. They are used to identify vehicle capabilities and functions needed to implement the operational concept.
The NASA Schedule Management Handbook provides guidance on developing and maintaining an integrated master schedule for NASA projects. It outlines roles and responsibilities, considerations for schedule management tools, and processes for pre-schedule development, developing the integrated master schedule, and ongoing status updates and maintenance. The handbook aims to help project managers and teams adhere to NASA requirements for sound schedule management practices.
The document discusses integrated architecture assessments for future crewed missions to the moon. It summarizes:
1) Experience has shown integrated architecture assessments are crucial to establish stable configurations that meet performance, cost and risk goals.
2) The analyses allow for mission-level trades to ensure efficient vehicle designs, allocation of design margins, and elimination of overlooked elements.
3) Preliminary analyses indicate the Ares V 51.0.47 and 51.0.48 concepts with the Altair lunar lander can achieve global access to the lunar surface through trades of delta-V, low lunar orbit loiter time, and temporal availability over the lunar nodal cycle.
The document discusses NASA's technology protection program, which aims to identify and protect mission critical information (MCI) from foreign threats. It outlines the technology protection process, which involves assessing technologies to identify MCI, evaluating vulnerabilities, selecting initial and final controls, and developing implementation plans. The process is facilitated by the Technology Protection Working Group and aims to balance security with continued information sharing and the NASA mission.
The document summarizes lessons learned from international partnerships between agencies like NASA and ESA. It discusses that successful partnerships require:
1) Early and clear definition of project baselines and interfaces to avoid surprises
2) Regular communication and recognition of differences in processes between agencies
3) Involving various capacities beyond just project management like external relations and legal
International cooperation for projects like the International Space Station require managing political changes that can impact programs and diplomatic skills to manage relationships between equal partners. Flexibility and understanding are essential for international exploration partnerships.
The goal of implementing Earned Value Management (EVM) in the EVA Systems Project Office (ESPO) was to utilize existing products and processes where possible to make them compatible with EVM. The presentation covered the Work Breakdown Structure, Organizational Breakdown Structure, Responsibility Assignment Matrix, Control Accounts, Work Packages, Planning Packages, Integrated Master Plan, and schedule integration using Primavera and Deltek Cobra tools. It also discussed interfaces with other processes and EVM integration with the prime contractor.
The document discusses influencing culture change within an organization. It outlines a process that includes initial planning, establishing a framework, rollout, and making the change stick. The process is then illustrated through an example of restructuring a NASA safety and mission assurance division during the transition away from the space shuttle program. The case study describes dreaming up a new vision, analyzing roles and structure, communicating the changes, and taking actions to continually reinforce the new culture.
This document discusses keys to making virtual communication work. It begins with an overview of communication challenges in general and for virtual teams specifically. It then provides tips for virtual teams such as establishing clear standards and norms, developing team charters, communicating vision and goals effectively, understanding different communication styles, and using structures like TREOA for presentations. The document concludes with references for further resources on virtual team management.
The document discusses systems engineering challenges and opportunities, including:
1) Growing mission complexity is exceeding our ability to manage risk, and system designs emerge from pieces rather than sound architectures, resulting in brittle systems.
2) Technical and programmatic sides of projects are poorly coupled, hampering decision making and increasing risk.
3) Too much focus on process comes at the expense of design quality, driving up costs and risk.
The document proposes addressing these with model-based systems engineering, architecture frameworks, and integrating technical and programmatic considerations through architecture.
NASA is transforming its aging facility portfolio into next generation centers through a strategic renewal process using the Kotter change model. The agency established a sense of urgency around renewing assets as 40% will be over 40 years old. A powerful guiding coalition was formed including agency leadership, center leadership, and project teams. A vision of renewing and modernizing facilities to sustain capabilities in efficient facilities was created. Communication of the vision and empowering others to act through center master plans and project teams is occurring. Short term wins are planned through visible renewal projects that expand stakeholder buy-in and consolidate improvements to further transform the agency's facilities portfolio.
This document discusses how to apply systems engineering principles to small, fast-paced projects with limited resources. It recommends tailoring systems engineering processes by deciding in advance how key elements will be addressed rather than questioning if they will be addressed. Checklists from NASA standards can help ensure critical items are considered. Organizational support, collaboration, and focused peer reviews are also important enablers.
This document discusses important considerations for forming effective project teams. It emphasizes selecting the right team members, establishing a shared vision and goals, clarifying roles and expectations, and ensuring the team understands its purpose. Specifically, it recommends selecting candidates based on their knowledge, skills, and abilities; developing a mission statement to guide the team's work; setting SMART goals to facilitate success; defining each member's responsibilities; and discussing the team's objectives during formation to set the stage for high performance. Forming the team carefully at the outset is critical to setting the foundation for successful collaboration.
The document describes a proposed Systems Engineering Leadership Development Program at Marshall Space Flight Center (MSFC) to address a deficiency in systems engineering expertise, particularly in leadership capabilities. The program would have two levels - Journeyman and Leader - requiring training courses and developmental assignments over 2 years. Level I focuses on basic competency while Level II targets leadership skills and involves a selection process. The program aims to enhance participants' skills and expand the qualified candidate pool for systems engineering roles at MSFC.
This document discusses the use of social media at NASA. It begins with an introduction to social media, defining it as internet-based applications that allow for the rapid creation and sharing of user-generated content. The document then discusses the relevance of social media for NASA projects and individuals. It provides examples of NASA's use of three major social media platforms: Twitter, Facebook, and blogs. It describes how NASA utilizes each platform and the benefits they provide for sharing information with the public. The document aims to demonstrate how NASA advocates for the use of social media to further engagement and outreach goals.
NASA is working to foster innovation and commercial partnerships through its Innovative Partnerships Program (IPP). IPP provides funding, expertise, facilities, and partnerships to advance technologies that can help achieve NASA's mission. It supports programs like SBIR/STTR that fund hundreds of small businesses annually, as well as seed funds, technology incubators, and prizes that leverage external resources to develop game-changing technologies. The goal is to bridge the gap between research and operational use, and to stimulate innovation that benefits both NASA and private industry.
The document discusses building communities of engineers to share technical expertise. It describes how NASA has established communities of practice on the NASA Engineering Network to facilitate knowledge sharing across distributed engineering disciplines. Specifically, it provides examples of communities of practice in fault management and autonomous rendezvous and docking that bring together experts from across NASA to collaborate on challenges in those fields.
The document discusses using the Technology Infusion and Maturation Assessment (TIMA) process developed by NASA's Jet Propulsion Laboratory to design and evaluate architectural options for the smart electric power grid in California. TIMA involves identifying key technologies, developing use cases, analyzing risks and barriers, and defining a technology roadmap. The goal is to meet California's energy and climate policy objectives through 2030 and beyond in a cost-effective manner.
The document discusses the systems engineering approach applied to the SOFIA program to address issues and help make it successful. It describes assessing the program's SE&I and identifying deficiencies. An incremental development approach was taken, breaking the work into phases. This allowed requirements and SE activities to catch up over time while continuing development and obtaining early science data for support. Risk management was also emphasized through identifying and tracking priority risks.
The SOFIA program was undergoing a replan and development phase while also having to address multiple new planning requirements and initiatives. This presented a juggling act challenge of managing everything simultaneously without impacting technical progress. The program leveraged existing functional groups and integrated new processes like a threat database to help sequence and prioritize new requirements. This allowed the program to focus on key priorities like flight testing while still addressing other reviews and audits. Coordinating across groups through techniques like tossing "balls" back and forth helped integrate schedules, budgets, and risk management to help manage the many moving parts.
The document discusses NASA's software engineering processes and requirements. It provides an overview of 12 key software engineering processes, including requirements management, planning and monitoring, measurement and analysis, software assurance, verification, configuration management, product integration, and their benefits. It also indicates which roles are typically involved with each process.
The document compares the operational complexity and costs of the Space Shuttle versus the Sea Launch Zenit rocket. [1] The Space Shuttle was designed for performance but not operational efficiency, resulting in costly ground, mission planning, and flight operations. [2] In contrast, the Zenit rocket was designed from the start to have automated and robust processes to keep operations simple and costs low. [3] The key lesson is that designing a launch system with operational requirements in mind from the beginning leads to much more efficient operations long-term.
The document provides an overview of project management and procurement at NASA. It discusses the key skills required for project managers, including acquisition management. It notes that 80-85% of NASA's budget is spent on contracts, and procurement processes are complex and constantly changing. The document outlines some common contract types and how they allocate risk between the government and contractor. It also discusses the relationship between contracting officers and project managers, and how successful procurement requires effective communication rather than direct control or authority.
The NASA Schedule Management Handbook provides guidance on developing and maintaining an integrated master schedule for NASA projects. It outlines roles and responsibilities, considerations for schedule management tools, and processes for pre-schedule development, developing the integrated master schedule, and ongoing status updates and maintenance. The handbook aims to help project managers and teams adhere to NASA requirements for sound schedule management practices.
The document discusses integrated architecture assessments for future crewed missions to the moon. It summarizes:
1) Experience has shown integrated architecture assessments are crucial to establish stable configurations that meet performance, cost and risk goals.
2) The analyses allow for mission-level trades to ensure efficient vehicle designs, allocation of design margins, and elimination of overlooked elements.
3) Preliminary analyses indicate the Ares V 51.0.47 and 51.0.48 concepts with the Altair lunar lander can achieve global access to the lunar surface through trades of delta-V, low lunar orbit loiter time, and temporal availability over the lunar nodal cycle.
The document discusses NASA's technology protection program, which aims to identify and protect mission critical information (MCI) from foreign threats. It outlines the technology protection process, which involves assessing technologies to identify MCI, evaluating vulnerabilities, selecting initial and final controls, and developing implementation plans. The process is facilitated by the Technology Protection Working Group and aims to balance security with continued information sharing and the NASA mission.
The document summarizes lessons learned from international partnerships between agencies like NASA and ESA. It discusses that successful partnerships require:
1) Early and clear definition of project baselines and interfaces to avoid surprises
2) Regular communication and recognition of differences in processes between agencies
3) Involving various capacities beyond just project management like external relations and legal
International cooperation for projects like the International Space Station require managing political changes that can impact programs and diplomatic skills to manage relationships between equal partners. Flexibility and understanding are essential for international exploration partnerships.
The goal of implementing Earned Value Management (EVM) in the EVA Systems Project Office (ESPO) was to utilize existing products and processes where possible to make them compatible with EVM. The presentation covered the Work Breakdown Structure, Organizational Breakdown Structure, Responsibility Assignment Matrix, Control Accounts, Work Packages, Planning Packages, Integrated Master Plan, and schedule integration using Primavera and Deltek Cobra tools. It also discussed interfaces with other processes and EVM integration with the prime contractor.
The document discusses influencing culture change within an organization. It outlines a process that includes initial planning, establishing a framework, rollout, and making the change stick. The process is then illustrated through an example of restructuring a NASA safety and mission assurance division during the transition away from the space shuttle program. The case study describes dreaming up a new vision, analyzing roles and structure, communicating the changes, and taking actions to continually reinforce the new culture.
This document discusses keys to making virtual communication work. It begins with an overview of communication challenges in general and for virtual teams specifically. It then provides tips for virtual teams such as establishing clear standards and norms, developing team charters, communicating vision and goals effectively, understanding different communication styles, and using structures like TREOA for presentations. The document concludes with references for further resources on virtual team management.
The document discusses systems engineering challenges and opportunities, including:
1) Growing mission complexity is exceeding our ability to manage risk, and system designs emerge from pieces rather than sound architectures, resulting in brittle systems.
2) Technical and programmatic sides of projects are poorly coupled, hampering decision making and increasing risk.
3) Too much focus on process comes at the expense of design quality, driving up costs and risk.
The document proposes addressing these with model-based systems engineering, architecture frameworks, and integrating technical and programmatic considerations through architecture.
NASA is transforming its aging facility portfolio into next generation centers through a strategic renewal process using the Kotter change model. The agency established a sense of urgency around renewing assets as 40% will be over 40 years old. A powerful guiding coalition was formed including agency leadership, center leadership, and project teams. A vision of renewing and modernizing facilities to sustain capabilities in efficient facilities was created. Communication of the vision and empowering others to act through center master plans and project teams is occurring. Short term wins are planned through visible renewal projects that expand stakeholder buy-in and consolidate improvements to further transform the agency's facilities portfolio.
This document discusses how to apply systems engineering principles to small, fast-paced projects with limited resources. It recommends tailoring systems engineering processes by deciding in advance how key elements will be addressed rather than questioning if they will be addressed. Checklists from NASA standards can help ensure critical items are considered. Organizational support, collaboration, and focused peer reviews are also important enablers.
This document discusses important considerations for forming effective project teams. It emphasizes selecting the right team members, establishing a shared vision and goals, clarifying roles and expectations, and ensuring the team understands its purpose. Specifically, it recommends selecting candidates based on their knowledge, skills, and abilities; developing a mission statement to guide the team's work; setting SMART goals to facilitate success; defining each member's responsibilities; and discussing the team's objectives during formation to set the stage for high performance. Forming the team carefully at the outset is critical to setting the foundation for successful collaboration.
The document describes a proposed Systems Engineering Leadership Development Program at Marshall Space Flight Center (MSFC) to address a deficiency in systems engineering expertise, particularly in leadership capabilities. The program would have two levels - Journeyman and Leader - requiring training courses and developmental assignments over 2 years. Level I focuses on basic competency while Level II targets leadership skills and involves a selection process. The program aims to enhance participants' skills and expand the qualified candidate pool for systems engineering roles at MSFC.
This document discusses the use of social media at NASA. It begins with an introduction to social media, defining it as internet-based applications that allow for the rapid creation and sharing of user-generated content. The document then discusses the relevance of social media for NASA projects and individuals. It provides examples of NASA's use of three major social media platforms: Twitter, Facebook, and blogs. It describes how NASA utilizes each platform and the benefits they provide for sharing information with the public. The document aims to demonstrate how NASA advocates for the use of social media to further engagement and outreach goals.
NASA is working to foster innovation and commercial partnerships through its Innovative Partnerships Program (IPP). IPP provides funding, expertise, facilities, and partnerships to advance technologies that can help achieve NASA's mission. It supports programs like SBIR/STTR that fund hundreds of small businesses annually, as well as seed funds, technology incubators, and prizes that leverage external resources to develop game-changing technologies. The goal is to bridge the gap between research and operational use, and to stimulate innovation that benefits both NASA and private industry.
The document discusses building communities of engineers to share technical expertise. It describes how NASA has established communities of practice on the NASA Engineering Network to facilitate knowledge sharing across distributed engineering disciplines. Specifically, it provides examples of communities of practice in fault management and autonomous rendezvous and docking that bring together experts from across NASA to collaborate on challenges in those fields.
The document discusses using the Technology Infusion and Maturation Assessment (TIMA) process developed by NASA's Jet Propulsion Laboratory to design and evaluate architectural options for the smart electric power grid in California. TIMA involves identifying key technologies, developing use cases, analyzing risks and barriers, and defining a technology roadmap. The goal is to meet California's energy and climate policy objectives through 2030 and beyond in a cost-effective manner.
The document discusses the systems engineering approach applied to the SOFIA program to address issues and help make it successful. It describes assessing the program's SE&I and identifying deficiencies. An incremental development approach was taken, breaking the work into phases. This allowed requirements and SE activities to catch up over time while continuing development and obtaining early science data for support. Risk management was also emphasized through identifying and tracking priority risks.
The SOFIA program was undergoing a replan and development phase while also having to address multiple new planning requirements and initiatives. This presented a juggling act challenge of managing everything simultaneously without impacting technical progress. The program leveraged existing functional groups and integrated new processes like a threat database to help sequence and prioritize new requirements. This allowed the program to focus on key priorities like flight testing while still addressing other reviews and audits. Coordinating across groups through techniques like tossing "balls" back and forth helped integrate schedules, budgets, and risk management to help manage the many moving parts.
The document discusses NASA's software engineering processes and requirements. It provides an overview of 12 key software engineering processes, including requirements management, planning and monitoring, measurement and analysis, software assurance, verification, configuration management, product integration, and their benefits. It also indicates which roles are typically involved with each process.
The document compares the operational complexity and costs of the Space Shuttle versus the Sea Launch Zenit rocket. [1] The Space Shuttle was designed for performance but not operational efficiency, resulting in costly ground, mission planning, and flight operations. [2] In contrast, the Zenit rocket was designed from the start to have automated and robust processes to keep operations simple and costs low. [3] The key lesson is that designing a launch system with operational requirements in mind from the beginning leads to much more efficient operations long-term.
The document provides an overview of project management and procurement at NASA. It discusses the key skills required for project managers, including acquisition management. It notes that 80-85% of NASA's budget is spent on contracts, and procurement processes are complex and constantly changing. The document outlines some common contract types and how they allocate risk between the government and contractor. It also discusses the relationship between contracting officers and project managers, and how successful procurement requires effective communication rather than direct control or authority.
The document introduces the NASA Engineering Network (NEN), which was created by the Office of the Chief Engineer to be a knowledge management system connecting NASA's engineering community. The NEN integrates various tools like a content management system, search engine, and collaboration tools. It provides access to key knowledge resources like NASA's Lessons Learned database and engineering databases. The NEN is working to expand by adding more communities, engineering disciplines, and knowledge repositories.
Laptops were first used in space in 1983 on the Space Shuttle, when Commander John Young brought the GRiD Compass portable computer on STS-9. Laptops are now widely used on the Space Shuttle and International Space Station for tasks like monitoring spacecraft systems, tracking satellites, inventory management, procedures viewing, and videoconferencing. Managing laptops in space presents challenges around cooling, power, and software/hardware compatibility in the harsh space environment.
Laptops were first used in space in 1983 on the Space Shuttle, when Commander John Young brought the GRiD Compass portable computer on STS-9. Laptops are now widely used on the Space Shuttle and International Space Station for tasks like monitoring spacecraft systems, planning rendezvous and proximity operations, inventory management, procedure reviews, and communication between space and ground via software like WorldMap and DOUG. Managing laptops in space presents challenges around hardware durability, cooling, and software/data management in the space environment.
This document discusses the use of market-based systems to allocate scarce resources for NASA missions and projects. It provides examples of how market-based approaches were used for instrument development for the Cassini mission, manifesting secondary payloads on the space shuttle, and mission planning for the LightSAR Earth imaging satellite project. The document finds that these applications of market-based allocation benefited or could have benefited from a decentralized, incentive-based approach compared to traditional centralized planning methods. However, it notes that resistance to new approaches and loss of managerial control are barriers to adoption of market-based systems.
The Stardust mission collected samples from comet Wild 2 and interstellar dust particles. It launched in February 1999 and encountered Wild 2 in January 2004, collecting dust samples in aerogel. It returned the samples to Earth safely in January 2006. The spacecraft used an innovative Whipple shield to protect itself from comet dust impacts during the encounter. Analysis of the Stardust samples has provided insights about comet composition and the early solar system.
This document discusses solutions for integrating schedules on NASA programs. It introduces Stuart Trahan's company, which provides Earned Value Management (EVM) solutions using Microsoft Office Project that comply with OMB and ANSI requirements. It also introduces a partner company, Pinnacle Management Systems, that specializes in enterprise project management solutions including EVM, project portfolio management, and enterprise project resource management, with experience in the aerospace, defense, and other industries. The document defines schedule integration and describes some methods including importing to a centralized Primavera database for review or using Primavera ProjectLink for updates, and challenges including inconsistent data formats and levels of detail across sub-schedules.
The document discusses NASA's implementation of earned value management (EVM) across its Constellation Program to coordinate work across multiple teams. It outlines the organizational structure, current target groups, and an EVM training suite. It also summarizes lessons learned and the need for project/center collaboration to integrate schedules horizontally and vertically.
This document summarizes a presentation about systems engineering processes for principle investigator (PI) mode missions. It discusses how PI missions face special challenges due to cost caps and lower technology readiness levels. It then outlines various systems engineering techniques used for PI missions, including safety compliance, organizational communication, design tools, requirements management, and lessons learned from past missions. Specific case studies from NASA's Explorers Program Office are provided as examples.
This document discusses changes to NASA's business practices for managing projects, including adopting a new acquisition strategy approach and implementing planning, programming, and budget execution (PPBE). The new acquisition strategy involves additional approval meetings at the strategic planning and project levels to better integrate acquisition with strategic and budgetary planning. PPBE focuses on analyzing programs and infrastructure to align with strategic goals and answer whether proposed programs will help achieve NASA's mission. The document also notes improvements in funds distribution and inter-center transfers, reducing the time for these processes from several weeks to only a few days.
Spaceflight Project Security: Terrestrial and On-Orbit/Mission
The document discusses security challenges for spaceflight projects, including protecting space assets from disruption, exploitation, or attack. It highlights national space policy principles of protecting space capabilities. It also discusses trends in cyber threats, including the increasing capabilities of adversaries and how even unskilled attackers can compromise terrestrial support systems linked to space assets if defenses are not strong. Protecting space projects requires awareness of threats, vulnerabilities, and strategies to defend, restore, and increase situational awareness of space assets and supporting systems.
Humor can positively impact many aspects of project management. It can improve communication, aid in team building, help detect team morale issues, and influence leadership, conflict management, negotiation, motivation, and problem solving. While humor has benefits, it also has risks and not all uses of humor are positive. Future research is needed on humor in multicultural teams, its relationship to team performance, how humor is learned, and determining optimal "doses" of humor. In conclusion, humor is a tool that can influence people and projects, but must be used carefully and spontaneously for best effect.
The recovery of Space Shuttle Columbia after its loss in 2003 involved a massive multi-agency effort to search a wide debris field, recover crew remains and evidence, and compensate local communities. Over 25,000 people searched over 680,000 acres, recovering 38% of Columbia's weight. Extensive engineering investigations were conducted to identify the causes of failure and implement changes to allow the safe return to flight of Discovery in 2005.
This document summarizes research on enhancing safety culture at NASA. It describes a survey developed to assess NASA's safety culture based on principles of high reliability organizations. The survey was tailored specifically for NASA and has been implemented to provide feedback and identify areas for improvement. It allows NASA to benchmark its safety culture within and across other industries pursuing high reliability.
This document summarizes a presentation about project management challenges at NASA Goddard Space Flight Center. The presentation outlines a vision for anomaly management, including establishing consistent problem reporting and analysis processes across all missions. It describes the current problem management approach, which lacks centralized information sharing. The presentation aims to close this gap by implementing online problem reporting and trend analysis tools to extract lessons learned across missions over time. This will help improve spacecraft design and operations based on ongoing anomaly experiences.
This document discusses leveraging scheduling productivity with practical scheduling techniques. It addresses scheduling issues such as unwieldy schedule databases and faulty logic. It then discusses taming the schedule beast through using a scheduler's toolkit, schedule templates, codes to manipulate MS Project data, common views/filters/tables, limiting constraints, and other best practices. The document provides examples of using codes and custom views/filters to effectively organize and display schedule information.
This document describes Ball Aerospace's implementation of a Life Cycle and Gated Milestone (LCGM) process to improve program planning, execution, and control across its diverse portfolio. The LCGM provides a standardized yet flexible framework that maps out program activities and products across phases. It was developed through cross-functional collaboration and introduced gradually across programs while allowing flexibility. Initial results showed the LCGM supported improved planning and management while aligning with Ball Aerospace's entrepreneurial culture.
This document discusses the importance of situation awareness (SA) for project team members. It defines SA as having three levels: perception of elements in the current situation, comprehension of the current situation, and projection of the future status. Good team SA is achieved by turning individual SAs into shared SA through communication. Teams with strong SA prepare more, focus on comprehending and projecting, and maintain awareness through techniques like questioning assumptions and seeking additional information.
This document discusses theories of leadership and how a project manager's leadership style may impact project success depending on the type of project. It outlines early hypotheses that a PM's competence, including leadership style, is a success factor on projects. It presents a research model linking PM leadership competencies to project success, moderated by factors like project type. Initial interviews found that leadership style is more important on complex projects, and different competencies are needed depending on if a project is technical or involves change. Certain competencies like communication skills and cultural sensitivity were seen as important for different project types and contexts.
Taking AI to the Next Level in Manufacturing.pdfssuserfac0301
Read Taking AI to the Next Level in Manufacturing to gain insights on AI adoption in the manufacturing industry, such as:
1. How quickly AI is being implemented in manufacturing.
2. Which barriers stand in the way of AI adoption.
3. How data quality and governance form the backbone of AI.
4. Organizational processes and structures that may inhibit effective AI adoption.
6. Ideas and approaches to help build your organization's AI strategy.
Your One-Stop Shop for Python Success: Top 10 US Python Development Providersakankshawande
Simplify your search for a reliable Python development partner! This list presents the top 10 trusted US providers offering comprehensive Python development services, ensuring your project's success from conception to completion.
Fueling AI with Great Data with Airbyte WebinarZilliz
This talk will focus on how to collect data from a variety of sources, leveraging this data for RAG and other GenAI use cases, and finally charting your course to productionalization.
Skybuffer SAM4U tool for SAP license adoptionTatiana Kojar
Manage and optimize your license adoption and consumption with SAM4U, an SAP free customer software asset management tool.
SAM4U, an SAP complimentary software asset management tool for customers, delivers a detailed and well-structured overview of license inventory and usage with a user-friendly interface. We offer a hosted, cost-effective, and performance-optimized SAM4U setup in the Skybuffer Cloud environment. You retain ownership of the system and data, while we manage the ABAP 7.58 infrastructure, ensuring fixed Total Cost of Ownership (TCO) and exceptional services through the SAP Fiori interface.
Monitoring and Managing Anomaly Detection on OpenShift.pdfTosin Akinosho
Monitoring and Managing Anomaly Detection on OpenShift
Overview
Dive into the world of anomaly detection on edge devices with our comprehensive hands-on tutorial. This SlideShare presentation will guide you through the entire process, from data collection and model training to edge deployment and real-time monitoring. Perfect for those looking to implement robust anomaly detection systems on resource-constrained IoT/edge devices.
Key Topics Covered
1. Introduction to Anomaly Detection
- Understand the fundamentals of anomaly detection and its importance in identifying unusual behavior or failures in systems.
2. Understanding Edge (IoT)
- Learn about edge computing and IoT, and how they enable real-time data processing and decision-making at the source.
3. What is ArgoCD?
- Discover ArgoCD, a declarative, GitOps continuous delivery tool for Kubernetes, and its role in deploying applications on edge devices.
4. Deployment Using ArgoCD for Edge Devices
- Step-by-step guide on deploying anomaly detection models on edge devices using ArgoCD.
5. Introduction to Apache Kafka and S3
- Explore Apache Kafka for real-time data streaming and Amazon S3 for scalable storage solutions.
6. Viewing Kafka Messages in the Data Lake
- Learn how to view and analyze Kafka messages stored in a data lake for better insights.
7. What is Prometheus?
- Get to know Prometheus, an open-source monitoring and alerting toolkit, and its application in monitoring edge devices.
8. Monitoring Application Metrics with Prometheus
- Detailed instructions on setting up Prometheus to monitor the performance and health of your anomaly detection system.
9. What is Camel K?
- Introduction to Camel K, a lightweight integration framework built on Apache Camel, designed for Kubernetes.
10. Configuring Camel K Integrations for Data Pipelines
- Learn how to configure Camel K for seamless data pipeline integrations in your anomaly detection workflow.
11. What is a Jupyter Notebook?
- Overview of Jupyter Notebooks, an open-source web application for creating and sharing documents with live code, equations, visualizations, and narrative text.
12. Jupyter Notebooks with Code Examples
- Hands-on examples and code snippets in Jupyter Notebooks to help you implement and test anomaly detection models.
leewayhertz.com-AI in predictive maintenance Use cases technologies benefits ...alexjohnson7307
Predictive maintenance is a proactive approach that anticipates equipment failures before they happen. At the forefront of this innovative strategy is Artificial Intelligence (AI), which brings unprecedented precision and efficiency. AI in predictive maintenance is transforming industries by reducing downtime, minimizing costs, and enhancing productivity.
This presentation provides valuable insights into effective cost-saving techniques on AWS. Learn how to optimize your AWS resources by rightsizing, increasing elasticity, picking the right storage class, and choosing the best pricing model. Additionally, discover essential governance mechanisms to ensure continuous cost efficiency. Whether you are new to AWS or an experienced user, this presentation provides clear and practical tips to help you reduce your cloud costs and get the most out of your budget.
Trusted Execution Environment for Decentralized Process MiningLucaBarbaro3
Presentation of the paper "Trusted Execution Environment for Decentralized Process Mining" given during the CAiSE 2024 Conference in Cyprus on June 7, 2024.
GraphRAG for Life Science to increase LLM accuracyTomaz Bratanic
GraphRAG for life science domain, where you retriever information from biomedical knowledge graphs using LLMs to increase the accuracy and performance of generated answers
Salesforce Integration for Bonterra Impact Management (fka Social Solutions A...Jeffrey Haguewood
Sidekick Solutions uses Bonterra Impact Management (fka Social Solutions Apricot) and automation solutions to integrate data for business workflows.
We believe integration and automation are essential to user experience and the promise of efficient work through technology. Automation is the critical ingredient to realizing that full vision. We develop integration products and services for Bonterra Case Management software to support the deployment of automations for a variety of use cases.
This video focuses on integration of Salesforce with Bonterra Impact Management.
Interested in deploying an integration with Salesforce for Bonterra Impact Management? Contact us at sales@sidekicksolutionsllc.com to discuss next steps.
Have you ever been confused by the myriad of choices offered by AWS for hosting a website or an API?
Lambda, Elastic Beanstalk, Lightsail, Amplify, S3 (and more!) can each host websites + APIs. But which one should we choose?
Which one is cheapest? Which one is fastest? Which one will scale to meet our needs?
Join me in this session as we dive into each AWS hosting service to determine which one is best for your scenario and explain why!
In the realm of cybersecurity, offensive security practices act as a critical shield. By simulating real-world attacks in a controlled environment, these techniques expose vulnerabilities before malicious actors can exploit them. This proactive approach allows manufacturers to identify and fix weaknesses, significantly enhancing system security.
This presentation delves into the development of a system designed to mimic Galileo's Open Service signal using software-defined radio (SDR) technology. We'll begin with a foundational overview of both Global Navigation Satellite Systems (GNSS) and the intricacies of digital signal processing.
The presentation culminates in a live demonstration. We'll showcase the manipulation of Galileo's Open Service pilot signal, simulating an attack on various software and hardware systems. This practical demonstration serves to highlight the potential consequences of unaddressed vulnerabilities, emphasizing the importance of offensive security practices in safeguarding critical infrastructure.
Building Production Ready Search Pipelines with Spark and MilvusZilliz
Spark is the widely used ETL tool for processing, indexing and ingesting data to serving stack for search. Milvus is the production-ready open-source vector database. In this talk we will show how to use Spark to process unstructured data to extract vector representations, and push the vectors to Milvus vector database for search serving.
Building Production Ready Search Pipelines with Spark and Milvus
Heitzman.askins
1. Ares I-X - The Integrated Master Schedule
(IMS)
Keith “Indiana” Heitzman, IMS Manager
Bruce Askins, Project Integration
Manager
Used with Permission Launched October 28, 2009
2. Chance Encounter in The Summer of Lean
Name 5'08 6'08 7'08 8'08 9'08 10'08 11'08 12'08 1'09 2'09 3'09 4'09 5'09
Frustum Delivered to ARF 8/4/08 9/18/08
Deliver to ARF 9/2/08 9/30/08
Forward Skirt Extension Delivered to ARF 8/4/08 11/7/08
Deliver to ARF 7/28/08 10/9/08
Forward Skirt Delivered to ARF 8/4/08 10/20/08
Deliver to ARF 6/13/08 9/8/08
Forward Assembly Sub Assemble 9/18/08 1/30/09
Sub Assemble 9/30/08 11/28/08
Forward 5th Seg Sim Delivered to ARF 7/30/08 12/30/08
Deliver to ARF 9/11/08 10/9/08
Center 5th Seg Sim Delivered to ARF 7/30/08 12/30/08
Deliver to ARF 9/11/08 10/9/08
Aft 5th Seg Sim Delivered to ARF 7/30/08 12/30/08
FSAM Need
Deliver to ARF 7/24/08 10/9/08
5th Segment Simulator Sub Assemble 1/30/09
12/30/08
Sub Assemble 10/9/08 11/28/08
Pwr On Launch
Ground Operations Stack & Integrated Testing
4/15/09
Pwr On Launch
Stack & Integrated Testing
12/1/08 2/15/09 4/15/09
2
3. Ares I-X Flight Test Objectives
♦ Demonstrate control of a dynamically
similar, integrated Ares I/Orion, using
Ares I relevant ascent control algorithms
♦ Perform an in-flight separation/staging
event between a Ares I-similar First Stage
and a representative Upper Stage
♦ Demonstrate assembly and recovery of a
new Ares I-like First Stage element at KSC
♦ Demonstrate First Stage separation
sequencing, and quantify First Stage
atmospheric entry dynamics, and
parachute performance
♦ Characterize magnitude of integrated
vehicle roll torque throughout
First Stage flight
National Aeronautics and Space Administration 7465.3
4. The Mission and The Name
The Mission Evolves The Name Evolves
♦Late 2005 – Team starts DFT
to take shape ADFT
♦Early 2006 – Scope and ADFT 1
Cost Creep
ADFT 0
♦Cancelled
Ares 1
♦May 2006 – Revived as a
relevant, cost & schedule Ares I-1
effective flight test
♦Apr 2007 – 1st Lean Event Ares I-X
~Feb 2007
& Project Re-org
4
6. IMS Before 1st Lean Event
♦ A confederation of Level 3, 4, & 5 elements
♦ Complex board structure
♦ The rhetoric of how to best integrate the IMS had to battle with
intra- and inter-center politics
• More energy expended to break through barriers than actually building
a good schedule
• Lack of trust
♦ No mission-level margin
♦ Not all elements working in Primavera
♦ Proper integration of the schedule was not going to happen.
♦ IMS integrations was done manually
♦ Many very talented people working hard to make it work
The First Lean Event was a pivotal point in schedule integration
6
7. 1st Lean Event Recommendations to CxCB
♦ Control Boards
• Current State – up to 10 boards (from contractor to CxP)
− Example: ~44 days (9 work weeks) of preparation and wait time for FTINU mod
• Ideal State – only value added boards
− Up to 4 boards (Contractor, Element, Engineering, and Project)
− FTINU mod could have been done in significantly less time (40 – 60 %)
• Benefits include increase in productivity and/or cost savings
♦ Rework Cycles (expected)
• Current State – high probability of rework
− Examples: FTINU, T-0 umbilical, vehicle stabilization, etc.
• Ideal State – eliminate rework cycles
− Integration up-front leads to ½ time reduction
− Eliminate rework (T-0 rework, vehicle stabilization, etc.)
♦ Schedule Margin
• Current State – None or risk of going over schedule
• Ideal State – Add ~45 to 60 business days of margin
− Provide incentives for contractors and civil service personnel
♦ Priorities
• Current State – unclear/everyone marching to a different drummer
• Ideal State – consistent
8. Ares I-X Org After First Lean Event
A Level 2 Project with IPT’s
Ares I-X Mission
Management Office
Mission Manager, Bob Ess
Safety & Mission Deputy, MSFC, Steve Davis
Deputy, KSC, Carol Scott Chief Engineers
Assurance CxP Liaison, TBD
Budget Analyst, JSC/TBD
Joe Brunty/MSFC
TBD/KSC
(S&MA) Project Integration, TBD
TBD Administrative Assistants
Support Staff
Systems Engineering
& Integration (SE&I)
Integrated Product Teams (IPTs)
Ground First Upper Stage Avionics Roll Control CM/LAS
Operations Stage Simulator and DFI System Simulator
(GO) (USS) (RoCS)
Jon Cowart/KSC Chris Calfee/MSFC Vince Bilardo/GRC Kevin Flynn/MSFC Ron Unger/MSFC Brian Beaton/LaRC
9. Ares I-X Organization at Launch
Safety & Mission Ares I-X Mission Chief Engineers
Assurance ( S& MA ) Management Office ( MMO )
Joe Brunty / MSFC
Dan Mullane / MSFC Vehicle CE
Bob Ess
Chief S&MA Officer
Mission Manager Shaun Green / KSC
Jeff Hamilton / MSFC Ground CE
Deputy Jon Cowart / KSC Steve Davis / MSFC
Deputy Deputy Dawn Stanley / MSFC
Angie Wise / MSFC Deputy Vehicle CE
Deputy Bruce Askins/ MSFC John Howell / MSFC Marshall Smith / LaRC
Project Integration Manager Business Manager SE&I Chief
Chris Duke / MSFC Systems Engineering
Business Manager Deputy
Project Integration (PI) & Integration (SE&I)
Bruce Askins / MSFC M. Smith / LaRC
Manager Chief
Ron Olsen / MSFC K. Detweiler / LaRC R. Barry Bryant / LaRC Henry Wright / LaRC
Deputy Lead Systems Engineer Deputy Chief Lead Engineer
Mike Bangham / MSFC Lanny Upton / MSFC Steve Richards / MSFC
Integrated Product Teams (IPTs) Deputy LSE Deputy LSE Deputy LSE
Ground CM/LAS
First Stage Avionics
Operations (GO) Simulator
Tassos Abadiotakis / KSC
Chris Calfee / MSFC Kevin Flynn / MSFC Jonathan Cruz / LaRC
Mike Chappell, Deputy Jay Nichols, Deputy Jeri Briscoe, Deputy Vacant, Deputy
Jim Bolton, Deputy
Ground Upper Stage Roll Control
Systems (GS) Simulator (USS) System (RoCS)
Mike Stelzer / KSC Vince Bilardo / GRC
Billy Stover, Deputy Bill Foster, Deputy Ron Unger / MSFC
Skip Williams, Deputy Jack Lekan, Deputy
National Aeronautics and Space Administration 9
10. The Summer of Lean
Goal: 60 Days Schedule Margin
♦ First Stage – Promontory, Utah
♦ Avionics – Denver, CO
♦ Roll Control – Huntsville, AL
♦ SE&I – Hampton, VA
♦ Upper Stage – Cleveland, OH
(attended by local participants and
facilitator only)
♦ Ground Ops/Ground Systems –
Cape Canaveral, FL
10
13. The Lean Machine
Developed a regular process for Schedule Lean Events
• Before Event
− Lots of pre-planning and working with facilitators
− Set schedule reduction goals for each area
− Scoped the event
− Indentify key participants Core Team – at all events
− Had local participants prepare current state • Leader – Steve Davis
• Facilitator – Mark Adrian
• At the Event – Monday Noon – Friday Noon • Integrator – Ron Olsen
− Kick-off and set the tone and pace • Scheduler – Keith Heitzman
− Informal report-outs mid-day & end of day • Strategic Participants
− Current state
− Ideal state
− Future state
− Incorporate IMS changes and verify savings ASAP
− Document key enablers for improving the process
− Final report out to champion
• After Event
− Incorporate changes to IMS and baseline
− Confirm that the detailed IMS matches the savings identified.
− Follow-up on enablers (tracked as action items for the project)
13
14. Primavera Pilot – It Works
♦ Primavera kicked-off by Constellation Program (CxP) in early
2006
♦ CxP wanted 3 projects to test Primavera
• Schedule – Primavera Project Management (PM)
• EVM – Primavera Cost Management (CM)
♦ Some growing pains early in implementation
• Primavera consultants provided to help get it going
• Most PM issues due to how it was set-up in ICE
− Deleted activities resurrected
− Printers disappeared
− Trouble developing reports
• CM issues seemed to be a combination of network and software issues
− CM was Abandoned
♦ Required training and a culture change
♦ The Schedule Tool (PM) worked as expected
♦ Had some issues with integration – KSC used their own
Primavera Database
A real-time integrated schedule would have been impossible without Primavera
14
15. Schedule Architecture & Reporting
Examples
2006 2007 2008 2009
O N D J F M A M J J A S O N D J F M A M J J A S O N D J F M A M J J A S O N D J
STS-119
STS-125/127 STS-128 STS-130
SRR PDR CDR 1 CDR 2
Post Flight
Analysis
Design
Hardware Fabricate & Assemble
Design Impl & Mod HMF ORR MLP/VAB/CCC ORR
Ground Systems PAD ORR
SIL Testing FTINU
Fwd Assy & 5SS Egineering
Fwd Assy & 5SS Fabrication
14
FSAM Fwd Assy & 5SS Processing
30 05
04 RoCS
USS 29
CM/LAS
19
Motor Segments
01
5th Seg Sim Fwd Assy
VAB High Bay 4 - Offline Stacking
23
Aft Skirt
RPSF Processing
26
VAB High Bay 3 - MLP Stacking & Testing Roll to Pad
Pwr On
Mate Review 30
FTRR 21
Pad Ops
Ares I-X Flight
Aug 30, 2009
15
16. Schedule Architecture
♦ Used Internet-based schedule environment that allowed the
entire mission to work in one logically tied, integrated, and live
schedule
• Max - 15 primary schedulers with 9 in Primavera
• 9 companies
• 6 geographic locations
• 1 IMS covering entire scope of mission
♦ Schedules – 3 Levels of Detail:
• Detailed IMS (Primavera) – detailed integration (~2,800 lines)
• Summary IMS (Primavera) – logically tied to the Detailed IMS and is
where the MMO manages schedule (~600 lines)
• Executive Summary IMS - 1 page quick-look
♦ Two versions of Summary IMS:
• Baseline Version
• Current Version
♦ Summary IMS Developed by MMO from a Mission Perspective
Managed IMS to the Right Level
16
17. Example of Detailed IMS to Summary IMS
links
Activity ID Activity Nam e Start Fin ish
Flight Tes t Vehicle
Ares I-X F 08-Aug-06 A 29-Aug-08
A3000 ATVC K ic koff 08-Aug-06 A
A18120 ATVC DE T IO P W A Elec . Des ign 13-Sep-06 A 01-O ct-07
A3020 ATVC FPG A DET Design 18-Sep-06 A 01-O ct-07
A3030 ATVC Design - Breadboard 20-O ct-06 A 18-Apr-07 A
A18140 ATVC DE T Pwr Sply I/F (PS I) PW A Elec. D... 01-Nov-06 A 01-O ct-07
A18150 ATVC Chassis Design 02-Nov-06 A 12-O ct-07
A18160 ATVC DE T MIB Design 07-Nov-06 A 01-O ct-07
A3080 ATVC Design - Proto-board 11-Dec-06 A 24-Jul-07 A
A18130 ATVC S RR/PDR 13-Dec-06 A
A18170 ATVC P roto Bd Tes t (MSFC) 15-Jun-07 A
A18180 ATVC CDR 25-Jun-07 A 26-Jun-07 A
A18190 ATVC Det Board Build & Test 06-Aug-07 A 10-O ct-07
A18210 ATVC S ys Test, Intgr & S hip DE T 1 (Denver ... 04-O ct-07* 31-O ct-07
A18240 ATVC (DE T 1) SIL Unit Delivery 31-O ct-07
A18220 ATVC Q U Board Build & Test 05-Dec-07* 16-Jan-08
A18200 ATVC Flight Board Build & Test 05-Dec-07* 11-Feb-08
A18260 ATVC S ys Test, Intgr - Q ual 30-Jan-08* 07-Jul-08
A18230 ATVC Q ual Tes t Readines s Review (Q TRR) 01-Feb-08*
A18250 Q ual Test Start 01-Feb-08*
A18270 ATVC S ys Test, Intgr & S hip - DFT-1 02-May-08* 31-Jul-08
A18280 ATVC S ys Test, Intgr & S hip - DFT-1 Spare 28-May-08* 29-Aug-08
A18300 Q ual Test Completion 07-Jul-08
A18290 ATVC Flight Unit 1 (Ares I-X) Delivery 31-Jul-08
Ares I-X S mary Sche dule
Sum 13-Sep-06 A 30-Jul-08
A23830 ATVC Design, Fab, Tes t 13-Sep-06 A 30-Jul-08
National Aeronautics and Space Administration 17
18. Schedule Management and Baseline Control
Summary IMS
♦ There are three reasons to propose a revision to the Baseline
IMS to the XCB:
• When a controlled milestone slips and cannot be recovered
• When there is a major scope change (+/-) to the mission
• When the Baseline IMS and Current IMS have diverged to the point
that warrants a complete re-baselining
♦ Proposed Baseline Changes were analyzed by the Schedule
Working Group (SWG) and then brought to the XCB by the SWG
♦ The Current IMS was statused weekly.
• Variances quickly calculated
• Baseline variances more than 10 days are analyzed and documented.
• Any change to controlled milestones analyzed first
♦ Higher level control milestones such as the FTRR and Launch
Date taken to Level 2 - CxCB and Level 1 - DPMC
Discipline and Control managing Baseline and Current IMS
18
19. Sample IPT Status in Summary IMS (RoCS)
A ctivity ID A ctivity Nam e S tart Finish V ariance - V ariance -
B L P roject B L P roject
ARES I-X-SUM A s I-X Sum m ary Sch ed ule
Are 19 -Se p-07 A 23 -Se p-08 0d 0d
ARES I-X-SUM.S Su m ma ry 19 -Se p-07 A 23 -Se p-08 0d 0d
ARES I-X-SUM
I-X-SUM.S.4 0 Ro CS 19 -Se p-07 A 23 -Se p-08 0d 0d
AR ES I-X-S UM .S .2 Ro CS Rev iew s
.S.40 03 -D ec-07 A 12 -Se p-08 0d 0d
A8 27 0 CD R Boa rd - R oC S 03 -D ec-07 A 0d 0d
A8 46 0 Ro CS - Pre -Sh ip / Ac cep tan ce Re vie w 12 -Se p-08* 0d 0d
AR ES I-X-S UM .S .3 Hardw a re A cq uis ition
.S.40 19 -Se p-07 A 17 -Ja n-0 8 A 0d -6 d
A8 44 0 Un it 8 D isas sem bled (fo r en gin e) 19 -Se p-07 A 10 -O ct-07 A 0d 0d
A1 30 10 Un it 9 D isas sem bled (fo r en gin e/o ptio n) 14 -N ov-07 A 06 -D ec-07 A -2 d 2d
A1 30 20 Un it 1 0 D isa sse mb led (for e ng ine/option ) 18 -D ec-07 A 17 -Ja n-0 8 A -6 d -6 d
AR ES I-X-S UM .S .4 Ro CS Bu ild
.S.40 03 -M ar-08 12 -Au g-08 -8 1d -2 3d
A8 45 0 Ro CS Bu ild - Q ua l Un it 03 -M ar-08* 26 -M ar-08 -8 1d -3 6d
A8 33 0 Ro CS Bu ild - F ligh t U nit 1 17 -M ar-08* 10 -Ju n-0 8 -8 1d -8 2d
A8 34 0 Ro CS Bu ild - F ligh t U nit 2 17 -M ar-08* 10 -Ju n-0 8 -3 1d 21 d
A2 10 80 Ro CS Bu ild - F ligh t U nit 3 (S pa re Unit) 28 -M ay-08* 12 -Au g-08 -8 2d -2 3d
AR ES I-X-S UM .S .5 Tes t
.S.40 31 -M ar-08 19 -Se p-08 -3 8d -1 0d
A8 49 0 Ro CS Q ual Un it P yro Te st 31 -M ar-08* 04 -Ap r-0 8 -3 8d -3 8d
A8 50 0 Co ld Flow T est 31 -M ar-08* 04 -Ap r-0 8 -3 8d -3 8d
A8 52 0 Ro CS De liv er Q ua l U nit for Fit Ch eck at GR C 02 -Ju n-0 8* 0d 0d
A8 51 0 Ro CS - Acc eptanc e T es ting - F ligh t U nit (1) 11 -Ju n-0 8* 09 -Ju l-0 8 -8 2d -6 2d
A2 10 90 Ro CS - Acc eptanc e T es ting - F ligh t U nit (2) 11 -Ju n-0 8* 09 -Ju l-0 8 21 d 41 d
A2 11 00 Ro CS - Acc eptanc e T es ting - F ligh t U nit (3) 22 -Au g-08* 19 -Se p-08 -3 0d -1 0d
AR ES I-X-S UM .S .7 Delive r to SIL (LM - D en ver)
.S.40 05 -O ct-07 A 05 -O ct-07 A 0d 0d
A2 43 80 Sh ip/ De live r to Lo ck hee d for SIL Te stin g (RoC S Valve... 05 -O ct-07 A 0d 0d
AR ES I-X-S UM .S .6 Delive r to KS C
.S.40 22 -Se p-08 23 -Se p-08 0d 0d
A8 53 0 Ro CS Arriv al a t K SC (Direc tly to H M F) 22 -Se p-08* 0d 0d
A8 56 0 Ro CS - RoC S Unlo ad ing / R ece ivin g / In spe ctio n 23 -Se p-08 23 -Se p-08 0d 0d
19
21. Communicating Total Float – Sample 1
Ares I-X 2008 2009
Total Float Jul Aug Sep Oct Nov Dec Jan Feb Mar Apr May
Sub-Assembly
Ground Ops High Bay 4 1/12
10/3
Stack and Test
System Integration
Float to Stack High Bay 3
Pad
27 Days
RoCS RoCS Arrives at KSC
Float to
27 Days
Upper Stage USS Arrives at KSC
14 Days
FTINU
CM/LAS CM/LAS Arrives at KSC
120 Days
RSRM Arrives at KSC
First Stage 27 Days Mission
Fwd Assy Delivery ARF to VAB 12 Days
0 Days
Float
5th Seg Simulator Delivery ARF to VAB
Aft Skirt Delivery ARF to RPSF
RPSF
Ground Stack and
Integrated
21 Days
Operations Testing
21 Days
Ready For FTINU Apr 15
Avionics FSAM Arrives at KSC 20 Days
Flt FTINU Arrives at KSC
Ready To Launch
3/27
21
22. Similarities: A Development Flight Test to a
Development IMS
♦ Needed to stand up an IMS before CxP had established
processes
♦ Scope creep – The IMS had to resist or adopt change much
like the rocket
• Rocket
− Added requirements from CxP
− Sensor additions/deletions
− Established processes from Centers
− Requests to “try out” new software tools or processes
• IMS
− CxP wanted to try new processes out on us or even impose requirements
− Primavera Pilot wanted us to use more of the tools than we needed
− Centers had process that may have been incongruent with needs of I-X
♦ Had to be successful – but still learn something
A proving ground that had to be successful
22
23. Monte Carlo – Use With Caution
♦ Started using Monte Carlo a few months after CDR
♦ Can approach diminishing returns – K.I.S.S.
• Use a separate, high level network (no open ends, no constraints)
• Keep it simple and do not burden the whole team
• Do analysis in small team, close to Project Manager
♦ Focus on Top Critical Paths & Risky Paths
♦ Results – May learn more in the journey than the destination
♦ Attack the tasks with most uncertainty (Tornado Chart)
• Success Story – Integrated Testing Duration 2 wks to 8 wks
a e au c
0.22 1.0
0.20 0.9
Cumulative Probability
0.17 0.8
0.7
Garbage In Garbage Out
Frequency
0.15
0.6
0.13
0.5
0.10
0.08
0.4
0.3
It’s a tool and not an exact science
0.05 0.2
0.03 0.1
Thu 9/24/09 Mon 10/12/09 Sun 11/1/09
Completion Date
23
24. Raw Data
2005 2006 2007 2008 2009
N D J F M A M J J A S O N D J F M A M J J A S O N D J F M A M J J A S O N D J F M A M J J A S O N
CxCB
ATP SRR PDR CDR 1 Launch
1st Baseline
CxCB
ATP SRR PDR CDR 1 CDR 2 Launch
Actual
♦ 18% schedule growth after CxP Authorization to Proceed
♦ Managed to the 4/15 Launch date for 2 years
• Started with 0 Margin
24
25. IMS – Good Practices
♦ The IMS is owned by the Team – not the schedulers
♦ Schedulers should have a technical background and
engineers should understand scheduling
♦ Manage the margin & float at as high a level as possible
• Discourage use of margin at lower levels
♦ Lean Events (Kaizens) are terrific tools
• Use early and often
• Do it right – don’t cheat yourself
♦ Manage using Total Float Paths (requires a healthy schedule)
♦ Start using Monte Carlo Analysis just before CDR
• It is just a tool and not an exact science
♦ Fancy software does not integrate a schedule
• Enterprise tools are great when used by a good schedule team
BUT… Don’t forget how important Human Factors & Org Structure is to
the IMS
25
26. More Than Good Scheduling
Human
Org Factors
Structure
Good
Schedule
Practices
Effective IMS
26
27. Thanks to the Ares I-X Schedulers
Amy McQuown Nick Kindred
Brian Schmid Paul Mc Masters
Chris Feagan Paul Kuhlken
Dan Healey Sonny Wood
Doug Pulling Steve McGraw
Jackie Cochran Susie Johnston
Kathy Drummond Tracy Kamm
Karen Russell Tammy Donaldson
Lloyd Johnson Viren Harris
Melanie Hawkins
27