Triple Your Chances of Project Success discusses the importance of requirements and risk management to project success. It notes that defining requirements and scope is critical to delivering projects on time and on budget. Not having a clear scope and requirements leads to increased risks such as cost overruns, schedule delays, and failure to meet stakeholder needs. The document recommends taking steps such as involving stakeholders, defining objectives, managing requirements changes, and following a formal requirements process to reduce risks and improve the chances of project success.
This document outlines NASA's 7-step project management process presented by the NASA Safety Center. The 7 steps are: 1) establish a vision, 2) develop project success criteria, 3) apply backward planning, 4) use forward action planning, 5) identify metrics, 6) rely on the project team, and 7) communicate frequently. Each step is described in 1-2 sentences with an emphasis on establishing a clear vision and success criteria early, planning backwards and forwards, using metrics to track progress, relying on team members, and ensuring open communication. Real NASA projects are provided as examples to illustrate applying the 7 steps.
This document discusses using performance-based competency standards (PBCS) to develop project managers. It explains that a PBCS defines the role, work units, and criteria for inferring competence of project managers. The document provides an example of assessing a project using complexity factors to determine the required role. It also gives examples of elements of competence and performance criteria that can be used for development by having project managers check their performance and provide documentary evidence.
The document provides an overview of key project management concepts and terms including the project management body of knowledge (PMBOK), the triple constraint of time, cost and scope, requirements definition, project charters, work breakdown structures, scheduling, earned value management, risk management, and configuration management. It emphasizes the importance of project planning, scope management, and using tools like the work breakdown structure, scheduling, and earned value management to track project performance and predict outcomes.
Project Management 2.0 involves using online collaboration tools to manage virtual teams more effectively. The NASA Dust Management Project used a tool called TeamLeader to plan and track tasks for its 30 team members across 8 field centers. TeamLeader consolidated planning, task management, file sharing, and reporting into one online workspace. This improved accountability, productivity, and knowledge transfer compared to prior email-based management. Challenges included overcoming resistance to change and training on the new technology, but engaging team members and facilitating the transition were keys to success.
The role of a Program Executive (PE) at NASA is multifaceted. PEs act as both an advocate for and enforcer of rules regarding their assigned projects. As an advocate, PEs defend projects, promote their science and success, and help navigate bureaucracy. As an enforcer, PEs ensure projects follow regulations and assess performance. Effective PEs build trust with projects and use communication and influence to jointly work towards the shared goal of mission success.
This document summarizes efforts by NASA's Dryden Flight Research Center to change its project execution culture through implementing Critical Chain Project Management tools and philosophies. The Dryden Center has around 550 civil service employees and 600 contractors working on 40+ active projects of varying sizes from multiple customers. Previously, the culture was characterized by unclear priorities, budget-driven staffing, poorly defined work, projects often in delay, and severe multi-tasking leading to delays, overruns, and workforce burnout. The desired new culture focuses on reducing multi-tasking and stress, improving on-time performance, and allowing more time for training through implementing techniques like staggered milestones, identifying and resolving issues quickly, and using buffers to set priorities.
The document describes the panelists and moderator for the "PM Challenge 2009 – “Making Risk Manageable” Panel. It provides brief biographies for each panelist: Nick Chrissotimos from NASA Goddard Space Flight Center, Joe Fuller from Futron Corporation, Richard Grou from the Canadian Space Agency, Mike McGrath from the University of Colorado, and John Turner from NASA Johnson Space Center. It also identifies the moderator, Peter J. Rutledge from Quality Assurance & Risk Management Services, Inc. Each panelist's biography highlights their relevant experience in project or program management, risk management, and space systems.
This document outlines NASA's 7-step project management process presented by the NASA Safety Center. The 7 steps are: 1) establish a vision, 2) develop project success criteria, 3) apply backward planning, 4) use forward action planning, 5) identify metrics, 6) rely on the project team, and 7) communicate frequently. Each step is described in 1-2 sentences with an emphasis on establishing a clear vision and success criteria early, planning backwards and forwards, using metrics to track progress, relying on team members, and ensuring open communication. Real NASA projects are provided as examples to illustrate applying the 7 steps.
This document discusses using performance-based competency standards (PBCS) to develop project managers. It explains that a PBCS defines the role, work units, and criteria for inferring competence of project managers. The document provides an example of assessing a project using complexity factors to determine the required role. It also gives examples of elements of competence and performance criteria that can be used for development by having project managers check their performance and provide documentary evidence.
The document provides an overview of key project management concepts and terms including the project management body of knowledge (PMBOK), the triple constraint of time, cost and scope, requirements definition, project charters, work breakdown structures, scheduling, earned value management, risk management, and configuration management. It emphasizes the importance of project planning, scope management, and using tools like the work breakdown structure, scheduling, and earned value management to track project performance and predict outcomes.
Project Management 2.0 involves using online collaboration tools to manage virtual teams more effectively. The NASA Dust Management Project used a tool called TeamLeader to plan and track tasks for its 30 team members across 8 field centers. TeamLeader consolidated planning, task management, file sharing, and reporting into one online workspace. This improved accountability, productivity, and knowledge transfer compared to prior email-based management. Challenges included overcoming resistance to change and training on the new technology, but engaging team members and facilitating the transition were keys to success.
The role of a Program Executive (PE) at NASA is multifaceted. PEs act as both an advocate for and enforcer of rules regarding their assigned projects. As an advocate, PEs defend projects, promote their science and success, and help navigate bureaucracy. As an enforcer, PEs ensure projects follow regulations and assess performance. Effective PEs build trust with projects and use communication and influence to jointly work towards the shared goal of mission success.
This document summarizes efforts by NASA's Dryden Flight Research Center to change its project execution culture through implementing Critical Chain Project Management tools and philosophies. The Dryden Center has around 550 civil service employees and 600 contractors working on 40+ active projects of varying sizes from multiple customers. Previously, the culture was characterized by unclear priorities, budget-driven staffing, poorly defined work, projects often in delay, and severe multi-tasking leading to delays, overruns, and workforce burnout. The desired new culture focuses on reducing multi-tasking and stress, improving on-time performance, and allowing more time for training through implementing techniques like staggered milestones, identifying and resolving issues quickly, and using buffers to set priorities.
The document describes the panelists and moderator for the "PM Challenge 2009 – “Making Risk Manageable” Panel. It provides brief biographies for each panelist: Nick Chrissotimos from NASA Goddard Space Flight Center, Joe Fuller from Futron Corporation, Richard Grou from the Canadian Space Agency, Mike McGrath from the University of Colorado, and John Turner from NASA Johnson Space Center. It also identifies the moderator, Peter J. Rutledge from Quality Assurance & Risk Management Services, Inc. Each panelist's biography highlights their relevant experience in project or program management, risk management, and space systems.
The document discusses project risk management and outlines the key steps: plan risk management, identify risks and opportunities, perform qualitative and quantitative risk analysis, plan risk responses, implement responses, and monitor risks. It defines risks as uncertain future events that could negatively impact objectives and opportunities as uncertain future events that could positively impact objectives. The risk assessment process determines the probability of a risk occurring and its potential impact. A risk matrix is provided as an example to assess risks based on probability and impact. The goal of risk management is to reduce risks and exploit opportunities to increase the likelihood of project success.
The document discusses structural barriers to effective systems engineering at NASA. It identifies several key barriers: programmatic barriers like unrealistic schedules and budgets; poor requirements definition allowing for unproven technology and unclear concepts of operations; and constraints limiting performance. It emphasizes that risk management is important but often poorly implemented, focusing on issues rather than risks and their root causes. Effective risk mitigation requires identifying risks, developing plans to directly address uncertainties, and ensuring adequate resources for risk resolution.
The document discusses managing scope creep in IT projects. It defines scope creep as occurring when the scope of a project expands without control. Scope creep happens due to poor requirements, lack of change control, underestimating complexity, and gold plating. After scope creep, projects miss deadlines, go over budget, and provide lower returns. To reduce scope creep, the document recommends implementing scope change control processes, defining clear requirements, and using agile methodologies with frequent stakeholder feedback.
Why Projects Fail + Four Steps to SucceedKevin Wordon
Understand why digital and IT projects fail and discover four simple project management tips to succeed.
Topics covered:
- Agile Decision Making
- The OODA Loop
- Clear Direction & Common Goals
- Defining Requirements
- Forming Your Project Team
This document introduces the Schedule Test and Assessment Tool (STAT) developed by NASA to assess schedule credibility. It provides an overview of STAT's capabilities, benefits of assessing schedules, and background on why schedule assessment is important. The document demonstrates STAT's schedule health check, trend analysis, and summary reporting features using example output. It summarizes that STAT enables efficient schedule assessment, quality improvement, and timely analysis through an easy-to-use automated tool.
This document provides an overview of a Microsoft Project 2007 training module that introduces participants to project management concepts and planning projects using Microsoft Project. The training covers topics such as the basics of project management, using Microsoft Project to plan tasks and resources, and project scheduling techniques like PERT charts and the critical path method. The course objectives are to teach participants how to identify, organize, manage and schedule tasks, resources, time and costs to complete a project.
This webinar discusses managing project scope and preventing scope creep. Scope creep occurs when additional functionality is added that was not in the original project requirements, potentially jeopardizing deadlines and budgets. Common causes of scope creep include poorly defined requirements, lack of change control, and gold plating by developers. Scope creep can be avoided by writing a detailed scope statement, ensuring accurate requirements, and establishing a formal change request process. Managing expectations and having a good rapport with stakeholders can help control scope changes.
This document provides an overview of NASA's software engineering benchmarking effort from February 2012. It discusses the background and motivation for the benchmarking, the organizations that were benchmarked, and the benchmarking team. It then summarizes some of the key learnings around training, testing, acquisition, small projects/processes, and the Capability Maturity Model Integration (CMMI). The document finds that mentoring is important for training, testing practices vary, acquisition of software requirements can be improved, tailoring is needed for small projects, and that CMMI adoption provides benefits like improved cost estimation and manageability.
This document provides an introduction to project management concepts for accidental project managers. It outlines the key things a project manager needs to know, including understanding the customer's problem, defining the deliverable, creating a project charter, scheduling tasks, managing risks, tracking status, and reporting progress. The presentation emphasizes that projects often fail because problems are created early on during planning, so getting proper buy-in from stakeholders and setting clear expectations is important for success.
This document provides an overview of key project management concepts including definitions of project management, the Project Management Body of Knowledge (PMBOK), and important processes like requirements definition, work breakdown structure, scheduling, and risk management. It also discusses project constraints, stakeholders, and offers advice on how to identify why projects fail and how to prevent failures.
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 conducting effective meetings. It provides guidelines for establishing meetings, preparing for meetings, conducting meetings, improving meetings, and follow up after meetings. Some key points include establishing a clear meeting purpose and intended results, creating an agenda, identifying participants, and establishing logistics. The document also discusses establishing measurable meeting results to determine if a meeting was successful.
The document provides an introduction to project management. It defines a project as a temporary work effort with a defined start and finish undertaken to create a unique product, service or result. Key characteristics of projects include being unique, having a definite start and end, and utilizing skills from multiple professions. The three main constraints of a project are time, cost, and performance quality. The document also discusses the project life cycle, which typically includes phases for concept, design, execution, and commissioning. It notes that project management involves applying knowledge and techniques to meet requirements within the constraints.
Seven Habits of a Highly Effective agile project managerGlen Alleman
Recent neurological studies indicate that the role of emotion in human cognition is essential; emotions are not a luxury. Instead, emotions play a critical role in rational decision–making, in perception, in human interaction, and in human intelligence. Habits are the intersection of knowledge, skill, and desire.
Studies show that many projects either fail outright or fail to meet most of their objectives. There are a myriad of possible reasons why this might be the case. Very often, organizations go looking for a culprit and sometimes blame the project manager or even the very concept of project management itself. Sometimes they decide to “fix” the problem by getting all the project managers certified. Or they decide to standardize on a certain tool. And while certification and standardization are laudable things, they do not necessarily address the central problem or problems. This presentation will discuss the top ten reasons why projects fail and briefly discuss solutions to each problem. We will see how such areas as estimates, scope and “the accidental project manager” contribute to the problem.
Control y seguimiento del proyecto herramientasProColombia
The document discusses metrics for project management. It recommends creating a small set of key metrics focused on cost, schedule, quality and user satisfaction that provide high-level information for management. Additionally, it suggests defining operational metrics to identify specific issues and risks. The document provides guidance on establishing a metrics program, including keeping the metrics and collection cycle simple and cost-effective to support better decision making.
Infographic - How a PMO/PPM tool like PM3 gives one version of the truth Bestoutcome
PM3, Bestoutcome's PPM tool, is designed by practitioners for practitioners. It provides a reporting hub that has one version of the truth for all your proojects and programnmes
This document discusses integrating risk and knowledge management practices at NASA's Exploration Systems Mission Directorate (ESMD). It outlines five practices ESMD has adopted: 1) establishing "Pause and Learn" processes to reflect on lessons; 2) generating and using "Knowledge-Based Risks" to convey lessons; 3) establishing "Communities of Practice" to share knowledge; 4) providing knowledge sharing forums; and 5) promoting experience-based training. The goal is for ESMD to effectively learn from the past and generate shared knowledge to help achieve the complex technical challenges of returning to the Moon and Mars.
The document outlines the LAUNCH initiative, which aims to accelerate sustainable development solutions through convening a council of global leaders to provide guidance and support to innovators working on sustainability challenges. The inaugural LAUNCH forum will focus on water sustainability and bring together a council representing different sectors to engage with 10 innovators and help accelerate the adoption of their solutions. NASA is a founding partner and will provide strategic guidance and leverage its expertise to help realize a more sustainable future.
This document outlines the investigation process of the NASA Organization Design Team. It describes three tracks of the investigation: 1) inviting lectures from program managers to identify best practices and lessons learned, 2) identifying tools to design and assess organizations, and 3) pilot studies applying those tools. The goal is to capture these lessons into a "toolkit" to disseminate organizational best practices across NASA. Track 1 involved 12 lectures on programs like Apollo, the F-117 stealth fighter, and submarines. The lectures explored organizational strategies for complex technical projects.
The document discusses project risk management and outlines the key steps: plan risk management, identify risks and opportunities, perform qualitative and quantitative risk analysis, plan risk responses, implement responses, and monitor risks. It defines risks as uncertain future events that could negatively impact objectives and opportunities as uncertain future events that could positively impact objectives. The risk assessment process determines the probability of a risk occurring and its potential impact. A risk matrix is provided as an example to assess risks based on probability and impact. The goal of risk management is to reduce risks and exploit opportunities to increase the likelihood of project success.
The document discusses structural barriers to effective systems engineering at NASA. It identifies several key barriers: programmatic barriers like unrealistic schedules and budgets; poor requirements definition allowing for unproven technology and unclear concepts of operations; and constraints limiting performance. It emphasizes that risk management is important but often poorly implemented, focusing on issues rather than risks and their root causes. Effective risk mitigation requires identifying risks, developing plans to directly address uncertainties, and ensuring adequate resources for risk resolution.
The document discusses managing scope creep in IT projects. It defines scope creep as occurring when the scope of a project expands without control. Scope creep happens due to poor requirements, lack of change control, underestimating complexity, and gold plating. After scope creep, projects miss deadlines, go over budget, and provide lower returns. To reduce scope creep, the document recommends implementing scope change control processes, defining clear requirements, and using agile methodologies with frequent stakeholder feedback.
Why Projects Fail + Four Steps to SucceedKevin Wordon
Understand why digital and IT projects fail and discover four simple project management tips to succeed.
Topics covered:
- Agile Decision Making
- The OODA Loop
- Clear Direction & Common Goals
- Defining Requirements
- Forming Your Project Team
This document introduces the Schedule Test and Assessment Tool (STAT) developed by NASA to assess schedule credibility. It provides an overview of STAT's capabilities, benefits of assessing schedules, and background on why schedule assessment is important. The document demonstrates STAT's schedule health check, trend analysis, and summary reporting features using example output. It summarizes that STAT enables efficient schedule assessment, quality improvement, and timely analysis through an easy-to-use automated tool.
This document provides an overview of a Microsoft Project 2007 training module that introduces participants to project management concepts and planning projects using Microsoft Project. The training covers topics such as the basics of project management, using Microsoft Project to plan tasks and resources, and project scheduling techniques like PERT charts and the critical path method. The course objectives are to teach participants how to identify, organize, manage and schedule tasks, resources, time and costs to complete a project.
This webinar discusses managing project scope and preventing scope creep. Scope creep occurs when additional functionality is added that was not in the original project requirements, potentially jeopardizing deadlines and budgets. Common causes of scope creep include poorly defined requirements, lack of change control, and gold plating by developers. Scope creep can be avoided by writing a detailed scope statement, ensuring accurate requirements, and establishing a formal change request process. Managing expectations and having a good rapport with stakeholders can help control scope changes.
This document provides an overview of NASA's software engineering benchmarking effort from February 2012. It discusses the background and motivation for the benchmarking, the organizations that were benchmarked, and the benchmarking team. It then summarizes some of the key learnings around training, testing, acquisition, small projects/processes, and the Capability Maturity Model Integration (CMMI). The document finds that mentoring is important for training, testing practices vary, acquisition of software requirements can be improved, tailoring is needed for small projects, and that CMMI adoption provides benefits like improved cost estimation and manageability.
This document provides an introduction to project management concepts for accidental project managers. It outlines the key things a project manager needs to know, including understanding the customer's problem, defining the deliverable, creating a project charter, scheduling tasks, managing risks, tracking status, and reporting progress. The presentation emphasizes that projects often fail because problems are created early on during planning, so getting proper buy-in from stakeholders and setting clear expectations is important for success.
This document provides an overview of key project management concepts including definitions of project management, the Project Management Body of Knowledge (PMBOK), and important processes like requirements definition, work breakdown structure, scheduling, and risk management. It also discusses project constraints, stakeholders, and offers advice on how to identify why projects fail and how to prevent failures.
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 conducting effective meetings. It provides guidelines for establishing meetings, preparing for meetings, conducting meetings, improving meetings, and follow up after meetings. Some key points include establishing a clear meeting purpose and intended results, creating an agenda, identifying participants, and establishing logistics. The document also discusses establishing measurable meeting results to determine if a meeting was successful.
The document provides an introduction to project management. It defines a project as a temporary work effort with a defined start and finish undertaken to create a unique product, service or result. Key characteristics of projects include being unique, having a definite start and end, and utilizing skills from multiple professions. The three main constraints of a project are time, cost, and performance quality. The document also discusses the project life cycle, which typically includes phases for concept, design, execution, and commissioning. It notes that project management involves applying knowledge and techniques to meet requirements within the constraints.
Seven Habits of a Highly Effective agile project managerGlen Alleman
Recent neurological studies indicate that the role of emotion in human cognition is essential; emotions are not a luxury. Instead, emotions play a critical role in rational decision–making, in perception, in human interaction, and in human intelligence. Habits are the intersection of knowledge, skill, and desire.
Studies show that many projects either fail outright or fail to meet most of their objectives. There are a myriad of possible reasons why this might be the case. Very often, organizations go looking for a culprit and sometimes blame the project manager or even the very concept of project management itself. Sometimes they decide to “fix” the problem by getting all the project managers certified. Or they decide to standardize on a certain tool. And while certification and standardization are laudable things, they do not necessarily address the central problem or problems. This presentation will discuss the top ten reasons why projects fail and briefly discuss solutions to each problem. We will see how such areas as estimates, scope and “the accidental project manager” contribute to the problem.
Control y seguimiento del proyecto herramientasProColombia
The document discusses metrics for project management. It recommends creating a small set of key metrics focused on cost, schedule, quality and user satisfaction that provide high-level information for management. Additionally, it suggests defining operational metrics to identify specific issues and risks. The document provides guidance on establishing a metrics program, including keeping the metrics and collection cycle simple and cost-effective to support better decision making.
Infographic - How a PMO/PPM tool like PM3 gives one version of the truth Bestoutcome
PM3, Bestoutcome's PPM tool, is designed by practitioners for practitioners. It provides a reporting hub that has one version of the truth for all your proojects and programnmes
This document discusses integrating risk and knowledge management practices at NASA's Exploration Systems Mission Directorate (ESMD). It outlines five practices ESMD has adopted: 1) establishing "Pause and Learn" processes to reflect on lessons; 2) generating and using "Knowledge-Based Risks" to convey lessons; 3) establishing "Communities of Practice" to share knowledge; 4) providing knowledge sharing forums; and 5) promoting experience-based training. The goal is for ESMD to effectively learn from the past and generate shared knowledge to help achieve the complex technical challenges of returning to the Moon and Mars.
The document outlines the LAUNCH initiative, which aims to accelerate sustainable development solutions through convening a council of global leaders to provide guidance and support to innovators working on sustainability challenges. The inaugural LAUNCH forum will focus on water sustainability and bring together a council representing different sectors to engage with 10 innovators and help accelerate the adoption of their solutions. NASA is a founding partner and will provide strategic guidance and leverage its expertise to help realize a more sustainable future.
This document outlines the investigation process of the NASA Organization Design Team. It describes three tracks of the investigation: 1) inviting lectures from program managers to identify best practices and lessons learned, 2) identifying tools to design and assess organizations, and 3) pilot studies applying those tools. The goal is to capture these lessons into a "toolkit" to disseminate organizational best practices across NASA. Track 1 involved 12 lectures on programs like Apollo, the F-117 stealth fighter, and submarines. The lectures explored organizational strategies for complex technical projects.
The document discusses integrating cost and schedule risk analysis using a risk driver approach. It presents a method for directly modeling schedule risk using risks identified in a risk register, specifying the probability and impact of each risk. This allows identifying priority risks that affect both cost and schedule. The results from this integrated analysis include the likelihood of schedule and cost success, contingency estimates, and a prioritized list of top risks ranked by their influence on time and cost. Accounting for relationships between cost, schedule and risk in this way provides a more accurate understanding of project uncertainty.
The document summarizes techniques for leveraging scheduling productivity with practical scheduling methods. It discusses taming unwieldy schedules by using schedule templates, codes to manipulate MS Project data, common views/filters/tables, and limiting constraints. It provides examples of reserving fields in templates and creating customized views and filters to manipulate schedule data in MS Project.
The Constellation Program Planning and Control office oversees planning, control, and integration activities for NASA's Constellation Program. It ensures proper implementation of NASA policies and procedures, including NASA Procedural Requirements 7120.5D which outlines life cycle project management requirements. Lessons learned from establishing the Constellation Program include thoroughly understanding 7120.5D requirements, having validated program baselines ready for review, and proactively engaging convening authorities and other stakeholders.
1) Organizational capability and predictability can be improved through intentional design rather than leaving it to chance. Simulation and rehearsal techniques allow organizations to test capabilities and adjust.
2) A case study compares simulating different owner-contractor relationship strategies for a project to quantify expected outcomes like costs, schedule variability, and quality. The dual player strategy improved predictability and reduced costs the most.
3) Simulation is most valuable when uncertainty is highest, such as during project conceptualization, team formation, or phase transitions, to improve communication, safety and prepare for challenges.
The document discusses 5 keys to successful project management: 1) Obtain good requirements, 2) Perform detailed project planning, 3) Do risk management, 4) Lead the project team, and 5) Create an organizational culture that supports project management. It provides details on each of the 5 keys, emphasizing the importance of requirements gathering, planning, risk management, leadership, and developing an organizational culture and maturity for supporting projects.
The document summarizes the challenges faced by the Cassini Program in managing the transition to an extended mission, including defining a minimum worthwhile science mission with reduced funding, descoping operations while maintaining science objectives, and designing a new mission plan with fewer encounters and longer orbits. It describes changes made for the solstice mission such as reduced overlapping activities, simpler sequences, and decreased resources.
The document provides information about NASA's Space Launch System (SLS) program. It discusses SLS's mandate to deliver the next human-rated space transportation system, provides a brief history of how SLS was developed, and explains why NASA believes SLS will succeed through its flexible and modular design approach. The presentation also outlines SLS's key objectives of being safe, affordable, and able to support a variety of exploration missions to destinations like near-Earth asteroids and Mars.
NASA has implemented CMMI models to improve software engineering processes. Key impacts include reduced risk, more accurate cost estimates, and finding defects earlier. NASA requires a minimum CMMI level for contractors depending on software class. Lessons learned are that preparation is critical, tools help achieve compliance, and cultural changes have significantly improved practices. CMMI provides a proven approach to manage performance if defined processes are used, results measured, and continuous improvements made.
The document discusses the benefits of using a model-based systems engineering (MBSE) approach to develop the architecture for Exploration Flight Test 1 (EFT-1), an unmanned test flight of the Orion spacecraft. Key benefits included providing an integrated view of the technical and programmatic aspects of the complex, distributed EFT-1 network system and managing technical baselines, risks, costs, and other program activities. The MBSE approach reduced documentation needs and enforced systems engineering rigor. Lessons learned included avoiding confusing terminology like "MBSE", taking time for stakeholder understanding and planning, and requiring discipline experts to use the modeling tool for systems engineering.
This document discusses how principles of Zen Buddhism can help with project management. It identifies 10 insights from Zen that can guide projects, including focusing on identity, timeliness, vision, simplicity, overcoming worries, balancing hierarchy with individualism, team play, discerning truth from illusion, motivation, and passion. Applying Zen can help inspire teams and interactions, build high-performing units, and deliver results that delight customers. Zen principles offer a process for mastering challenges and achieving success and balance in projects.
This document summarizes a project to improve ground system designs for NASA by incorporating human factors principles. It discusses the importance of considering ground crews, outlines pathfinder activities including an overview for design teams and working sessions, and provides examples of human-system integration challenges. The goal is to design systems that are safer and easier for ground crews to operate over 20+ years to reduce costs from mishaps and improve safety.
The document discusses lessons learned from the Orbiting Carbon Observatory (OCO) mission. It provides an overview of OCO, which was designed to measure atmospheric carbon dioxide from space but failed to reach orbit after launch. Despite the mission ending quickly, the project team conducted a close-out process to collect lessons from all members. Key lessons included the need to maintain a single requirements database, test flight hardware under expected conditions before integration, and plan early for efficient data transfer. The lessons will help improve the proposed OCO-2 reflight mission.
Montressa L. Washington gave a presentation on using crowdsourcing, collaboration and Web 2.0 tools to enhance project management. She discussed how Enterprise 2.0 allows for new collaboration patterns through tools like wikis, blogs and social networks. Examples were given of how crowdsourcing, collaboration and social media can be used in project management, such as using ideation platforms for crowdsourcing ideas and online communities to facilitate collaboration. Web 2.0 tools like social bookmarks and profiles can also help with knowledge sharing and finding expertise.
The document discusses the benefits and challenges of interagency collaboration for NASA missions, noting that partnerships can improve capabilities, augment budgets, and foster innovation, but developing and sustaining partnerships can be challenging due to differences in agency cultures and competing resource demands. It provides examples of elements needed for successful partnerships, including clear shared goals, ongoing assessment of progress, and real investment and commitment from both partners.
The document discusses the RD-180 rocket engine partnership between the United States and Russia. It summarizes that the RD-180 engine, produced in Russia, has been successfully integrated into the Atlas V launch vehicle in the US, improving its reliability, payload capacity, and reducing costs. Government involvement from both countries was critical to establishing the joint venture and addressing policy, export control, and technical integration challenges over time. The partnership demonstrates the potential for mutually beneficial international cooperation in the space industry.
This document discusses how human factors requirements influenced rocket design for the Constellation Program (CxP). It describes how requirements were developed based on crew health, safety, and performance. It then discusses how a requirement around human tolerance for vibration led to further analysis showing gaps in knowledge about crew performance during and after vibration. This prompted the formation of a Thrust Oscillation Focus Team to analyze thrust oscillation issues and identify mitigation strategies to reduce predicted vibration responses and risks to the vehicle, spacecraft, and crew from vibration.
The document discusses integrating cost and schedule risk analysis using a risk driver approach. It presents a method for directly modeling schedule risk using risks identified in a risk register, specifying the probability and impact of each risk. This allows identifying priority risks that affect both cost and schedule. The results from this integrated analysis include the likelihood of schedule and cost success, contingency estimates, and a prioritized list of top risks ranked by their influence on time and cost. Accounting for relationships between cost, schedule and risk in this way provides a more accurate understanding of project uncertainty.
This document provides a checklist for common requirement risk factors in project management. It identifies risks associated with scope, requirements, and requirement management. Potential impacts of these risks are described. The document also provides recommendations for mitigating scope risks, requirement risks, and requirement management risks. This includes developing clear goals and concepts, following a requirements process, allocating sufficient time and resources, and training the project team.
Episode 20 : PROJECT MANAGEMENT CONTEXT
Project phase and the Project Life Cycle
Project Stakeholders
Organizational Influences
Key General Management Skills
Social-Economic-Environmental Influences
SAJJAD KHUDHUR ABBAS
Chemical Engineering , Al-Muthanna University, Iraq
Oil & Gas Safety and Health Professional – OSHACADEMY
Trainer of Trainers (TOT) - Canadian Center of Human
Development
The document discusses risk management for projects. It begins by defining what a risk is and listing the benefits of risk management. It then outlines the key processes in risk management: plan risk management, identify risks, perform qualitative and quantitative risk analysis, plan risk responses, and monitor and control risks. Examples are provided for each step, including how to create a risk registry to track identified risks. The document emphasizes that risk management should be integrated throughout the project and communicate risks to stakeholders. It concludes with rules for effective risk management.
Андрій Мудрий «Risk managemnt: Welcome to Risk World»Lviv Startup Club
Kyiv Project Management Day 2017 Spring
-------------------------
Андрій Мудрий «Risk managemnt: Welcome to Risk World»
-------------------------
Сайт конференції: http://pmday.org/
Спільнота в мережі Linkedin: http://bit.ly/PMDayLin
Спільнота в мережі facebook: http://bit.ly/PMDayKyivFB
Twitter конференції: https://twitter.com/LvivPMDay
Андрій Мудрий “Risk managemnt: Welcome to Risk World” Lviv Project Managemen...Lviv Startup Club
The document discusses risk management for projects. It begins by defining what a risk is and listing the benefits of risk management. It then outlines the key processes in risk management: plan risk management, identify risks, perform qualitative and quantitative risk analysis, plan risk responses, and monitor and control risks. Examples are provided for each step, including how to create a risk registry to track identified risks. The document emphasizes that risk management should be integrated throughout the project and communicate risks to stakeholders. It concludes with rules for effective risk management.
The document discusses requirement management and analysis. It covers creating and using a requirement work plan (RWP), the components and purpose of an RWP, and a case study on developing an RWP. It describes an RWP as a to-do list for requirement elicitation, documentation, and validation. The key components of an RWP include a work breakdown structure (WBS), which lists all tasks and activities, and identifies resources, skills, effort, and milestones. Traceability and managing requirement changes and dependencies throughout the project lifecycle are also addressed.
Need to present lean project tools and techniques through a presentation? Not to worry! Download SlideTeam’s best lean project management PowerPoint presentation template. You can easily impart your business information with help of our lean practices PowerPoint slides. Download now: https://www.slideteam.net/lean-project-management-powerpoint-presentation-slide.html
Need to present lean project tools and techniques, SlideTeam offers you the lean project management PowerPoint Presentation. You can easily impart your business information with help of this lean practices PowerPoint slides. This lean thinking presentation templates contain slides on project planning process, dimensions of business planning, elements of project lifecycle, business objective, business scope, program phases, critical path, activity planner, week scheduler, yearly scheduler, tasks status dashboard, work breakdown structure, planning stages, work process, team management, planning and timeline, concept development, activity network, risk identification, progress against baseline schedule, alternatives evaluation and budgeting. With this lean manufacturing PowerPoint template, you can showcase various topics like six sigma, startup business, waste management, enterprise planning, improvement process, risk assessment, value stream mapping, and construction planning and change management. You can save time and enhance your Presentation skills by using our lean project management PowerPoint Presentation. Our Lean Project Management Powerpoint Presentation Slide will further your efforts. Their effect will draw in a bigger applause.
The document discusses software requirement engineering. It begins by introducing the software development life cycle (SDLC) and its phases. It then discusses why requirement engineering (RE) is important, noting that many project failures are due to issues with requirements gathering and documentation. The document outlines the root causes of project success and failure according to a study, which found the top three factors were lack of user input, incomplete requirements, and changing requirements. Finally, it defines what a requirement is and discusses the sub-disciplines of requirements development including elicitation, analysis, specification, and validation.
The document discusses various aspects of requirements engineering including processes, techniques, challenges, and importance. It describes requirements elicitation, analysis, specification, validation, and management. Key points covered include feasibility studies, types of requirements, characteristics of good requirements, requirements traceability and evolution. Diagrams like use cases, activity diagrams and data flow diagrams are presented as examples of requirements specification outputs.
This document provides an overview of lean project management. It includes slides on project planning processes, dimensions of project planning, project lifecycles, types of projects, project objectives, scope, schedules, work breakdown structures, risk identification, budgets, and timelines. The slides appear to be from a presentation on lean project management fundamentals and processes.
1. The document provides an overview of software project management, including its history, key roles and skills, common project phases, and classic mistakes.
2. It discusses the fundamentals of project management, introducing concepts like the triple and quadruple constraints of scope, time, cost, and quality.
3. Thirty-six common "classic mistakes" are categorized into people-related, process-related, product-related, and technology-related issues that can undermine software projects.
This document provides an overview of risk management for project sponsors. It discusses key project management concepts like the project management process, roles and responsibilities of sponsors and managers, and the importance of managing scope, schedule and budget. It then covers the risk management process, including identifying common risks like schedule and budget slippage, lack of clear requirements, and ineffective sponsorship. It provides symptoms, consequences and mitigating actions for addressing each risk.
This document summarizes key aspects of agile software development processes. It discusses that software development involves managing risks, and that agile processes are designed to help manage risks that change rapidly, unlike traditional waterfall approaches. It outlines some common risks in software projects. It then provides a brief history of software development processes, from waterfall to more iterative agile methods. Finally, it summarizes some core values and practices of agile development, such as rapid delivery of working software, transparency, reducing waste, and continuous improvement through retrospectives.
This document provides an overview of software project management. It begins with introductions and discusses the field of project management, including common jobs, professional organizations, certifications, and tools. It then covers the history of project management and key skills required for project managers, including positions in the field. The document defines what constitutes a software project and explains the engineering and management dimensions. It outlines several classic mistakes to avoid in software project management.
During the Agile Austria Conference 2017, Graz, Austria
Speaker: Fariz Saracevic
This session will examine how requirements management can bring significant value to agile development teams.
IT Quality Testing and the Defect Management ProcessYolanda Williams
This document provides an overview of defect management processes. It discusses defining defects, defect prevention, discovery, resolution and process improvement. The key aspects covered are:
- Defining goals as preventing defects, early detection, minimizing impact and process improvement.
- Activities like root cause analysis, escape analysis and process metrics.
- The defect lifecycle of prevention, discovery, resolution and continuous improvement.
- Examples of defect analysis and status reporting including metrics like density, backlog and mean time to repair.
Microsoft Dynamics AX Implementation Stabilization Case Studiesmeritweb
Learn about the risks, challenges, and best practices for implementing Microsoft Dynamics AX in enterprise manufacturing and supply chain environments. Hear about a couple of our Microsoft Dynamics AX implementation stabilization case studies.
Project Management In Our Changing WorldRandy Dunson
This document summarizes a panel discussion on project management in a changing world. The panelists discussed how most successful project managers started as accidental project managers, and the three major contributors to project success: requirements management processes, using a formal methodology and standardized tools, and executive management support. They also discussed how project management needs to adapt to a fast-paced changing world. The panelists provided their views on shifting away from command and control approaches and what the future of project management may look like.
Develop a Defect Prevention Strategy—or Else!TechWell
This document discusses the importance of defect prevention in software development. It notes that testing schedules are longer and more costly for low-quality projects compared to high-quality projects. The document advocates shifting investments from failure activities like testing to prevention activities earlier in the lifecycle like requirements reviews and static analysis. A framework is presented for establishing a defect prevention program that includes establishing teams, providing training, and measuring prevention efforts. Specific prevention techniques discussed include code reviews, static analysis, and addressing requirement ambiguities.
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.
Enhancing Adoption of AI in Agri-food: IntroductionCor Verdouw
Introduction to the Panel on: Pathways and Challenges: AI-Driven Technology in Agri-Food, AI4Food, University of Guelph
“Enhancing Adoption of AI in Agri-food: a Path Forward”, 18 June 2024
SATTA MATKA DPBOSS KALYAN MATKA RESULTS KALYAN CHART KALYAN MATKA MATKA RESULT KALYAN MATKA TIPS SATTA MATKA MATKA COM MATKA PANA JODI TODAY BATTA SATKA MATKA PATTI JODI NUMBER MATKA RESULTS MATKA CHART MATKA JODI SATTA COM INDIA SATTA MATKA MATKA TIPS MATKA WAPKA ALL MATKA RESULT LIVE ONLINE MATKA RESULT KALYAN MATKA RESULT DPBOSS MATKA 143 MAIN MATKA KALYAN MATKA RESULTS KALYAN CHART
DPBOSS NET SPBOSS SATTA MATKA RESULT KALYAN MATKA GUESSING FREE KALYAN FIX JO...essorprof62
DPBOSS NET SPBOSS SATTA MATKA RESULT KALYAN MATKA GUESSING FREE KALYAN FIX JODI ANK LEAK FIX GAME BY DP BOSS MATKA SATTA NUMBER TODAY LUCKY NUMBER FREE TIPS ...
SATTA MATKA DPBOSS KALYAN MATKA RESULTS KALYAN CHART KALYAN MATKA MATKA RESULT KALYAN MATKA TIPS SATTA MATKA MATKA COM MATKA PANA JODI TODAY BATTA SATKA MATKA PATTI JODI NUMBER MATKA RESULTS MATKA CHART MATKA JODI SATTA COM INDIA SATTA MATKA MATKA TIPS MATKA WAPKA ALL MATKA RESULT LIVE ONLINE MATKA RESULT KALYAN MATKA RESULT DPBOSS MATKA 143 MAIN MATKA KALYAN MATKA RESULTS KALYAN CHART
The Most Inspiring Entrepreneurs to Follow in 2024.pdfthesiliconleaders
In a world where the potential of youth innovation remains vastly untouched, there emerges a guiding light in the form of Norm Goldstein, the Founder and CEO of EduNetwork Partners. His dedication to this cause has earned him recognition as a Congressional Leadership Award recipient.
SATTA MATKA DPBOSS KALYAN MATKA RESULTS KALYAN CHART KALYAN MATKA MATKA RESULT KALYAN MATKA TIPS SATTA MATKA MATKA COM MATKA PANA JODI TODAY BATTA SATKA MATKA PATTI JODI NUMBER MATKA RESULTS MATKA CHART MATKA JODI SATTA COM INDIA SATTA MATKA MATKA TIPS MATKA WAPKA ALL MATKA RESULT LIVE ONLINE MATKA RESULT KALYAN MATKA RESULT DPBOSS MATKA 143 MAIN MATKA KALYAN MATKA RESULTS KALYAN CHART INDIA MATKA KALYAN SATTA MATKA 420 INDIAN MATKA SATTA KING MATKA FIX JODI FIX FIX FIX SATTA NAMBAR MATKA INDIA SATTA BATTA
AI Transformation Playbook: Thinking AI-First for Your BusinessArijit Dutta
I dive into how businesses can stay competitive by integrating AI into their core processes. From identifying the right approach to building collaborative teams and recognizing common pitfalls, this guide has got you covered. AI transformation is a journey, and this playbook is here to help you navigate it successfully.
The Steadfast and Reliable Bull: Taurus Zodiac Signmy Pandit
Explore the steadfast and reliable nature of the Taurus Zodiac Sign. Discover the personality traits, key dates, and horoscope insights that define the determined and practical Taurus, and learn how their grounded nature makes them the anchor of the zodiac.
Prescriptive analytics BA4206 Anna University PPTFreelance
Business analysis - Prescriptive analytics Introduction to Prescriptive analytics
Prescriptive Modeling
Non Linear Optimization
Demonstrating Business Performance Improvement
NIMA2024 | De toegevoegde waarde van DEI en ESG in campagnes | Nathalie Lam |...BBPMedia1
Nathalie zal delen hoe DEI en ESG een fundamentele rol kunnen spelen in je merkstrategie en je de juiste aansluiting kan creëren met je doelgroep. Door middel van voorbeelden en simpele handvatten toont ze hoe dit in jouw organisatie toegepast kan worden.
63662490260Kalyan chart, satta matta matka 143, satta matka jodi fix , matka boss OTC 420, Indian Satta, India matka, matka ank, spbossmatka, online satta matka game play, live satta matka results, fix fix fix satta namber, free satta matka games, Kalyan matka jodi chart, Kalyan weekly final anl matka 420
Cover Story - China's Investment Leader - Dr. Alyce SUmsthrill
In World Expo 2010 Shanghai – the most visited Expo in the World History
https://www.britannica.com/event/Expo-Shanghai-2010
China’s official organizer of the Expo, CCPIT (China Council for the Promotion of International Trade https://en.ccpit.org/) has chosen Dr. Alyce Su as the Cover Person with Cover Story, in the Expo’s official magazine distributed throughout the Expo, showcasing China’s New Generation of Leaders to the World.
3. NASA OIG
• “Program risks increase when contracts are awarded
before developing a sound business case and clearly
defining requirements;”
– Placing “the project at risk of significant cost overruns,
schedule delays, and performance shortfalls.”
GAO
• If Programs do not match requirements with resources,
cost overruns and schedule delays are likely to occur
Standish Group CHAOS Chronicles 2003 report
• Losing sight of requirements is often the first step on
the road to projects that come in over budget, are late,
do not meet specifications or are canceled.
3
4. Importance of Best Requirement Practices
on Project Success
• “The companies using best requirements practices will estimate
a project at $3 million and better than half the time will spend
$3 million on that project.
– Including all failures, scope creep, and mistakes across the entire
portfolio of projects, this group will spend, on average, $3.63 million per
project.”
• “The companies using poor requirements practices will estimate
a project at $3 million and will be on budget less than 20% of
the time.
– 50% of time, the overrun on the project both in time and budget will be
massive.
– Across the entire portfolio of successes and failures, this company with
poor requirements practices will (on average) pay $5.87 million per
project.”
2008 Study by Keith Ellis, IAG Consulting of 100
companies with projects in excess of $250,000 5
5. Setting Yourself Up for Failure
• Project success is “improbable” for 68% of the
companies Ellis studied
• While these companies indicated they
recognized that requirements are important to
project success, they still failed to take effective
actions to insure a good set of requirements.
• By doing so, they tripled their chances of project
failure
2008 Study by Keith Ellis, IAG Consulting of 100
companies with projects in excess of $250,000
6. A Winning Product
• Delivers what’s needed
• Within budget
• Within schedule
• With desired quality
Risk: Anything that can prevent you
from delivering a winning product!
8
7. What are risks?
• Risks are something that could have an
impact on your product or subsystem (hazard
or threat)
• Two major components
– Likelihood
– Impact/Consequence
9
9. Scope Risk Factors (Before Requirements)
• Failure to define Scope
• Failure to define Need, goals, and objectives
• Failure to involve relevant stakeholders
• Failure to identify drivers and constraints
• Failure to define a feasible concept to meet the
stakeholder needs
• Failure to define product boundaries and external
interfaces
• Failure to baseline scope before writing requirements
11
10. Consequences of Scope Risks (1)
• Product purpose/use not well understood
• Stakeholder’s expectations not met
• No agreement on criteria for success
• Vague or undefined desired outcomes
• Lack of direction/Lack of vision
• Possible conflicts due to a lack of a single clear vision
• Battles due to differing visions
• Constant/Uncontrolled Change
• Insufficient knowledge to write requirements
• Increased time to develop requirements
• Missing requirements
12
11. Consequences of Scope Risks (2)
• To many assumptions
• Incorrect information/incorrect requirements
• Inconsistent, incorrect, and incomplete requirements
• Non compliance
• Lack of robustness to handle off-nominal cases
• Could fail to work when interacting with other systems
• Do work you don’t need to do
• Scope creep
• Rework
• Cost & schedule impacts
• Leave out work you should have done
Fail System Validation 13
12. Identify Scope Risks
• Do we have product boundary questions?
• Have we missed a key stakeholder?
• Have we missed a product life-cycle phase?
• Are there areas of strong disagreement?
• Are there technical issues?
• Are there schedule issues?
• Are there cost issues?
• Are there any resource availability issues?
• Are there too many uncertainties?
Yes = High risk No = Low risk
14
13. Mitigating Scope Risk
• Develop a clear vision
– Identify the Need
– Define clear goals and objectives
• Identify and involve relevant stakeholders
• Identify and manage drivers and constraints
• Develop operational concepts
• Identify and manage external interfaces
• Identify and manage scope risk
• Baseline Scope (before writing requirements)
15
15. Requirement Risk Factors
• Requirement not necessary
• Requirement not verifiable
• Requirement not attainable
• Requirement can be understood more than one way
(ambiguous)
• Requirement(s) incomplete
• Requirement reflects implementation
• Requirement(s) subject to change
• Requirements not allocated (flowed down)
• Requirements not traceable to a parent
17
16. Consequences of Requirement Risks (1)
• Increased requirement management cost
• Work performed that is not needed
• Less resources for needed requirements
• Increased project cost
• Wrong implementation
• Incorrect verification (verify wrong thing)
• Stakeholder expectations not met
• Wasted effort
• Cost & Schedule impacts
• Performance expectations not met (technology not mature
enough)
• Requirement(s) can not be implemented
• Requirement(s) not be implemented
• Non-compliance with drivers and constraints
• Non-compliance with changed standards
• Could fail to work when interacting with other systems 18
17. Consequences of Requirement Risks (2)
• Real requirement not addressed and not flowed down (allocated)
properly
• Parent requirement not properly implemented
• Could be at the wrong level
• Solution space restricted by implementation – better solution not
defined
• Rework
• Possible conflicts or inconsistencies
• Wrong requirement(s) implemented
• Missing requirements at lower levels
• Could miss an internal interface
• Incomplete change assessment
• Gold plating – requirement not needed
Fail System Verification 19
18. Something to Think About
A quick and inexpensive way
to improve testing
Bell Labs and IBM
studies have determined
80% of all defects
are inserted
in the
requirements phase
— Testing Techniques
Newsletter
20
20. Mitigating Requirement Risk
• Define and enforce a requirement development process
• Follow the rules for writing good requirements
• Include key attributes: rationale, traceability, verification
method, allocation, priority, risk
• Train your requirement writers, management,
developers, testers, reviewers on how to write defect
free requirements
• Practice continuous requirement validation
• Identify and manage requirement risk
• Baseline Requirements
22
22. Requirement Management Risk Factors
• No official process
• Have a process but process not followed
• Not enough time and resources allocated to define and
baseline scope
• Not enough time and resources allocated to develop and
baseline requirements
• Poor change management
24
23. Consequences of Requirement Management Risks
– Wasted resources
– Scope risk factors
– Requirement risk factors
– Lack of feasible concept to meet stakeholder expectations
– Lack of/poor/incomplete direction to developers
– Uncontrolled change
– Unnecessary rework
– Cost and schedule impacts
– Stakeholder expectations not met
Failure to deliver a winning product
25
24. Mitigating Requirement Management Risk
• Allocate sufficient time and resources to define and baseline
Scope
• Allocate sufficient time and resources to develop and baseline
requirements
• Use requirement attributes to manage requirements
• Develop and enforce a formal requirement development and
management process
• Train team in your requirement development and management
process
• Manage change
26
26. Mitigating Change Risk
• Do the best job you can the first time
– Define and baseline your scope before writing requirements
– Do not baseline a bad document
– Put as much rigor in the baseline as in the changes that will follow
• “Design for change”
• Establish criteria for change
28
28. Parting Thoughts
• Address scope and requirement risk at the beginning of your
project.
– Identify and involve your stakeholders
– Identify drivers and constraints and external interfaces.
– Develop operational concepts that are thoroughly thought out
in the beginning of a project to allow the writing of better and
more comprehensive requirements.
• Develop, implement, and enforce a formal requirement
development and management process that includes continuous
requirement validation.
• Pay particular attention to your change management process.
• Train your team and enforce the requirement development and
management process through project leadership.
• Allocate the time and resources needed to do the job right – the
first time.
Triple your changes of project success 30
29. Putting Requirement Risk in the Proper Perspective
Not to put too much pressure on you….
• The Requirements Document is probably the single most
influential piece of paper that we have control over in the
entire Program.
• This is our chance to make sure that we are asking for
what we really want. Let’s get it right.
• This is a big, fat, hairy deal. If we don’t get this right, folks
20 years from now will be shaking their heads and saying,
“What were those yahoos thinking?”
– I’ll be around and don’t want to go to that meeting.
CxP EVA Suit PGS Team Requirement Kickoff Mtg 5/2007
31
30. No Surprises
“People who write bad requirements
should not be surprised
when they get bad products
But they
always are.”
Ivy Hooks
32
31. Parting Thought
“Putting forth the same effort, or using the
same approach, then expecting different results
is...insanity”
33
32. References (1)
CAI Requirements Development and Management, Seminar Workbook, February 2010, Compliance
Automation, Inc. 2010.
Ellis, Keith. Business Analysis Benchmark – The impact of Business Requirements on the success of
technology projects, IAG Consulting, 2008.
GAO-03-598, Matching Resources with Requirements Is Key to the Unmanned Combat Air Vehicle
Program’s Success, United States General Accounting Office, June, 2003.
<http://www.gao.gov/new.items/d03598.pdf>.
Hill, T. R. and Wheatcraft, L. S., Getting Started on the Right Foot: Developing Requirements for
Constellation’s Next Generation Space Suit, presentation at NASA’s PM Challenge, Galveston, Texas,
February 2010, and paper presented at INCOSE 2010 International Workshop, Chicago, Illinois, July
2010.
Hooks, I. F. and Farry, K. A., Customer-Centered Products: creating successful products through smart
requirements management; AMACOM Books, NY, NY, 2001.
INCOSE, Systems Engineering Handbook - a guide for system life cycle processes and activities, Version
3.1, INCOSE-TP-2003-002-03.1, August 2007, ed, Cecilia Haskins.
ISO/IEC 15288, System Engineering-System Life Cycle Processes, October 2002.
NASA OIG, Inspector General, NASA’s Most Serious Management and Performance Challenges, Report,
November 2008. <http://oig.nasa.gov/NASA2008ManagementChallenges.pdf>.
NASA, System Engineering Handbook, SP-2007-6105, Rev. 1, December 2007.
<http://education.ksc.nasa.gov/esmdspacegrant/Documents/NASA%20SP-2007-
6105%20Rev%201%20Final%2031Dec2007.pdf>.
34
33. References (2)
NASA, Systems Engineering Processes and Requirements, NPR 7123.1A, March 2007
<http://nodis3.gsfc.nasa.gov/displayDir.cfm?Internal_ID=N_PR_7120_005D>.
NASA, Space Flight Program and Project Management Requirements, NPR 7120.5D, March
2007. <http://nodis3.gsfc.nasa.gov/displayDir.cfm?Internal_ID=N_PR_7120_005D>.
NASA, Space Flight Program and Project Management Handbook, NPR 7120.5, February
2010.
< http://www.nasa.gov/pdf/423715main_NPR_7120-5_HB_FINAL-02-25-10.pdf >.
Software Engineering Institute, CMMI for Development – Improving processes for better
products, Version 1.2, CMMI Product Team, Carnegie Mellon, August 2006.
The Standish Group Report, CHAOS Chronicles, 1995 and 2003
Wheatcraft, L. S. and Hooks, I. F., Scope Magic, 2001.
<http://www.complianceautomation.com>.
Wheatcraft, L. S. The Importance Of Scope Definition Prior to Developing Space System
Requirements. INCOSE INSIGHT, Vol. 4 Issue 4, January 2002.
<http://www.complianceautomation.com>.
Wheatcraft, L. S. Delivering Quality Products That Meet Customer Expectations. Published in
CrossTalk, The Journal of Defense Software Engineering, January 2003, Vol. 16 No. 1.
<http://www.complianceautomation.com>.
Wheatcraft, L. S. Developing Requirements for Technology-Driven Products. Presented at
INCOSE 2005, July 2005. <http://www.complianceautomation.com>.
35
34. BIOGRAPHY
• Lou Wheatcraft has over 40 years experience in the aerospace
industry, including 22 years in the United States Air Force. Over
the last 10 years, Lou has worked for Compliance Automation
(dba Requirements Experts), where he has conducted over 140
seminars on requirement development and management for
NASA, Department of Defense (DoD), and industry. Lou has
had articles published in the International Council of Systems
Engineering (INCOSE) INSIGHT magazine and in DoD’s
magazine, CrossTalk.
• Lou has made presentations at NASA’s PM Challenge, INCOSE’s International Symposium,
and at the local Project Management Institute (PMI) and INCOSE Chapter Meetings. Lou has
a BS degree in Electrical Engineering, an MA degree in Computer Information Systems, an
MS degree in Environmental Management, and has completed the course work for an MS
degree in Studies of the Future.
• Lou is a member of INCOSE, co-chair of the INCOSE Requirements Working Group, a member
of PMI, the Software Engineering Institute, the World Futures Society, and the National
Honor Society of Pi Alpha Alpha. Lou is the recipient of NASA’s Silver Snoopy Award and
Public Service Medal and was nominated for the Rotary Stellar Award for his significant
contributions to the Nation’s Space Program.
36
Editor's Notes
NASA’s Office of Inspector General (OIG) November 2008 report [OIG 2008] focused on five major challenges; one of which concerns acquisition and contracting processes. The OIG concluded that: “NASA must be vigilant in its process of establishing and validating project requirements.” Program risks increase when contractual obligations are established before developing a sound business case and clearly defining requirements; placing “the project at risk of significant cost overruns, schedule delays, and performance shortfalls. Effective risk management, safety, and mission assurance controls are key to supporting robust and reliable operations in the context of very challenging launch and mission schedules.” (Emphasis added.)
A Winning Product vs. RiskThe goal of all projects should be to deliver a winning product. A winning product is defined herein as: “A product that delivers what is needed, within budget, within schedule, and with the desired quality.” A simple and practical definition of risk is: “Anything that can prevent you from delivering a winning product!” Given the importance of requirements to the success of a project, poor requirements represent a major project risk. Risks are something that could have an impact on your product or subsystem (hazard or threat). Risk has two major components: likelihood and impact/consequences. In the following discussion, the scope risk factors are things you have control over. Failing to follow these best practices means the likelihood is 100%. The possible impact or consequences listed are what you are trying to avoid.
Scope Risk FactorsFailure to define ScopeFailing to define your project and product scope can have major impacts and consequences on your ability to deliver a winning product. The product purpose/use will not be well understood resulting in not being able to meet stakeholder expectations. Failing to define scope also can result in your team being faced with vague and undefined desired outcomes, lacking the knowledge they need to write requirements, setting your project team up for failure. If your team lacks clear direction due to a lack of a common vision, the volatility and divergence of individual visions will result in conflicts between stakeholders and a constant stream of issues. These will lead to constant change, which, in turn, will have significant impacts on your budget and schedule.Failure to define Need, goals, and objectivesThe Need for a project defines the “why” – why are we doing this? What are we trying to accomplish? The Need is based on an analysis of a problem that the project is supposed to solve for some stakeholder or group of stakeholders. Goals are those things that you plan to accomplish that will result in meeting the Need. Objectives are measures of performance, including key performance parameters that show that you have met the goals. Objectives show that you have “gotten there”, i.e., your project accomplished what was expected of it by the stakeholders.Failing to define the Need, goals, and objectives for your project results in your team being faced with vague and undefined desired outcomes with no clear direction. Failing to define your objectives, means you have not defined, and gotten agreement on, the criteria for success.
Mitigating Scope RiskThe defense against all these risk factors is to clearly define your project’s scope at the beginning and then validate that scope with all the key stakeholders, getting their agreement on the scope before proceeding with writing your requirements. The largest scope risk, by far, is wishful thinking (budget/cost, schedule, and technology). To avoid the scope risks discussed above, include the following in your requirement development and management process:Develop a clear vision – identify the Need, goals, and objectives for your project and product.Identify and involve relevant stakeholdersIdentify and manage drivers and constraintsDevelop operational conceptsIdentify and manage external interfacesIdentify and manage scope riskBaseline Scope (Scope Review or Mission Concept Review)
Requirement Risk FactorsRequirement not necessaryA mandatory characteristic of a requirement is that it is needed. If a requirement is not needed, why is it in the requirement set? Requirements that are not necessary result in increased management cost of the requirements that, in turn, increases overall project costs and leaves less resources for needed requirements. All requirements need to be maintained, managed, and verified. Un-needed requirements can result in work being performed that is not necessary, taking resources away from the implementation of those requirements that are needed. In addition, implementing requirements that are not necessary can result in degraded system performance as well as introducing a potential source of failure and conflict.Requirement not verifiableAnother mandatory characteristic of a requirement is that it must be verifiable. Why ask for something when you can’t prove it has been implemented as intended? A requirement that is not verifiable could result in the developers implementing the wrong thing or the people doing verification verifying the system does the wrong thing rather than what was intended. If the true intent of the requirement is not clear, stakeholder expectations may not be met.Requirement not attainableAnother mandatory characteristic of a requirement is that it must be attainable. Why state a requirement you know cannot be implemented given the existing budget, schedule, or level of technical maturity? Why state a requirement when you haven’t done the assessment on whether or not it can be implemented within your existing budget, schedule, or level of technical maturity? Stating a requirement that is not attainable will result in wasted effort, cost and schedule impacts, as well as stakeholder expectations (performance) not being met.
Mitigating Requirement RiskThe defense against all these risk factors is to clearly define your requirements before beginning development.Do the best job you can to ensure you have a well written set of requirements. To avoid the requirement risks discussed above, include the following in your requirement development and management process:Define and enforce a requirement development processFollow the “Writing Good Requirements Checklist” (Contact Requirements Experts for a copy.)Include key attributes: rationale, traceability, verification method, allocation, priority, riskTrain your requirement writers, management, developers, testers, reviewers on how to write defect free requirementsPractice continuous requirement validation. Don’t allow defective requirements you’re your requirement set. Project managers should not wait until the major milestone reviews, especially the System Requirement Review (SRR), to find out they have a bad set of requirements. There is always the danger that sub-par requirements will be baselined, especially if there is a multitude of problems with the requirements at the SRR and the schedule is tight. Baselining bad requirements always leads to wasted resources needed to correct the requirements - putting the project at risk of schedule and budget overruns. Identify and manage requirement riskBaseline Requirements (SRR)
No official process/process not followedNot having an official process for managing requirements or having a process but the process in not followed will result in wasted resources as well as all the scope and requirement risk factors discussed earlier.Not enough time and resources allocated to define and baseline scopeFailing to allocate sufficient time and resources to define and baseline your project and product scope will result in the scope risk factors discussed earlier. In addition, you will not have defined and baselined a feasible concept that, when implemented, will meet stakeholder expectations. Not having a baselined scope will also result in constant change and scope creep, impacting your cost and schedule.
Not enough time and resources allocated to develop and baseline requirementsFailing to allocate sufficient time and resources to define and baseline your project and product requirements will result in the requirement risk factors discussed earlier. In addition, the direction to developers will be poorly communicated, ambiguous, incomplete, and inconsistent. Not having a baselined set of good requirements will result in constant change and requirements creep, again severely impacting your cost and schedule.Poor change managementThe result of not having or not enforcing a well defined change management process can result in uncontrolled change, scope creep, and requirements creep. Without some clear criteria for which changes are allowed, defective and unnecessary requirements will get into your set of requirements. You will be allowing change to control your project rather than you controlling change. Uncontrolled change results in both unnecessary rework and unneeded work, both of which will result in significant cost and schedule impacts as shown in Figure 2.
Mitigating Requirement Management RiskAs stated for both mitigating scope risk and requirement risk, the defense against all requirement management risk factors is to follow the best practices stated.Do the best job you can, the first time. To avoid the requirement management risks discussed above, include the following in your requirement development and management planning:Allocate sufficient time and resources to define and baseline Scope before writing requirements (Define your scope first, baseline and control it. This is absolutely the most critical first step in the requirements process.)Allocate sufficient time and resources to develop and baseline requirements.Use requirement attributes to manage requirements.Develop and enforce a formal requirement development and management process.Train your team in your requirement development and management process.Manage change
In conclusion, avoid the risks associated with poor requirement development and management practices by adopting the risk mitigation for each of the risk areas discussed in this paper and adopt the following requirement development and management best practices for your project:Address scope and requirement risk at the beginning of your project. Defining scope results in understanding stakeholder expectations. If you don’t, you are setting your project up for failure and probably will not be able to develop a product that meets stakeholder expectations. It is worthwhile to do the best job up-front to ensure the scope of your project is clearly understood, is feasible, is agreed to, and baselined. This results in a firm foundation to develop and manage your requirements. Identify drivers and constraints and external interfaces as part of the scope definition process. Develop operational concepts that are thoroughly thought out in the beginning of a project to allow the writing of better and more comprehensive requirements. This will eliminate rework and multiple recertification cycles later in the product lifecycle, preventing cost overruns and schedule slips.Develop, implement, and enforce a formal requirement development and management process that includes continuous requirement validation. This is critical during the initial development push as well as during final requirement development, development of the corresponding verification requirements, and managing your requirements.Pay particular attention to your change management process. If you don’t control change, change will control you. Changes to requirements result in design changes and rework, which impact schedule and budget. Frequently, these design changes are larger and more expensive than planned. Train your team and enforce the requirement development and management process through project leadership. Do not only send team members to training, but have them use the language taught in training, set up processes to match what is presented during training, and invest in either continual “refresher training” or provide a mentor to ensure a learned behavior is followed by the team; the process must be learned and it does not come naturally to most. Allocate the time and resources needed to do the job right – the first time. Small investments early on will provide large dividends later in saved or avoided costs and schedule slips.