Difference between revisions of "Technical Planning"

From SEBoK
Jump to navigation Jump to search
m (Text replacement - "SEBoK v. 2.9, released 20 November 2023" to "SEBoK v. 2.10, released 06 May 2024")
 
(151 intermediate revisions by 16 users not shown)
Line 1: Line 1:
−
The scope of the planning can vary between planning a specific task and developing a major technical plan. The integrated planning effort will determine what level of planning and documentation of that planning is appropriate for the project. The integration of each plan with other higher level, peer, or subordinate plans is an essential part of SE planning.   For the technical effort, the systems engineering management plan (SEMP), also known as the systems engineering plan (SEP), is the highest level technical plan.   It is subordinate to the Project Plan, and often has a number of subordinate technical plans providing detail on specific technical focus areas.
+
----
 +
'''''Lead Authors:''''' ''Ray Madachy, Garry Roedler, Brian Wells''
 +
----
 +
Planning is an important aspect of [[Systems Engineering Management|systems engineering management]] (SEM). {{Term|Systems Engineering (glossary)|Systems engineering}} (SE) planning is performed concurrently and collaboratively with project planning. It involves developing and integrating technical plans to achieve the technical project objectives within the resource constraints and {{Term|Risk (glossary)|risk}} thresholds. The planning involves the success-critical stakeholders to ensure that necessary tasks are defined with the right timing in the {{Term|Life Cycle (glossary)|life cycle}} in order to manage acceptable risks levels, meet schedules, and avoid costly omissions.
 +
 +
==SE Planning Process Overview==
 +
SE planning provides the following elements:
 +
* Definition of the {{Term|Project (glossary)|project}} from a technical perspective.  
 +
* Definition or tailoring of engineering processes, practices, methods, and supporting enabling environments to be used to develop products or services, as well as plans for transition and implementation of the products or services, as required by agreements.
 +
* Definition of the technical organizational, personnel, and team functions and responsibilities, as well as all disciplines required during the project life cycle.
 +
* Definition of the appropriate {{Term|Life Cycle Model (glossary)|life cycle model}} or approach for the {{Term|Product (glossary)|products}} or {{Term|Service (glossary)|services}}.
 +
* Definition and timing of technical reviews, product or service assessments, and control mechanisms across the life cycle, including the success criteria such as {{Term|Cost (glossary)|cost}}, schedule, and technical performance at identified project milestones.
 +
*Estimation of technical cost and schedule based on the effort needed to meet the requirements; this estimation becomes input to project cost and schedule planning.
 +
*Determination of critical technologies, as well as the associated risks and actions needed to manage and transition these technologies.
 +
*Identification of linkages to other project management efforts.
 +
*Documentation of and commitment to the technical planning.
 +
===Scope===
 +
SE planning begins with analyzing the {{Term|Scope (glossary)|scope}} of technical work to be performed and gaining an understanding the constraints, risks, and objectives that define and bound the solution space for the product or service. The planning includes estimating the size of the work products, establishing a schedule (or integrating the technical tasks into the project schedule), identification of risks, and negotiating commitments. Iteration of these planning tasks may be necessary to establish a balanced plan with respect to cost, schedule, technical performance, and quality.  The planning continues to evolve with each successive life cycle phase of the project (NASA 2007, 1-360; SEI 1995, 12).
  
−
Task planning identifies the specific work products, deliverables, and success criteria for systems engineering effort in support of integrated planning and project objectives. The success criteria are defined in terms of cost, schedule, and technical performance at identified project milestones. Detailed task planning identifies specific resource requirements (skills, equipment, facilities, dollars) as a function of time and project milestones.
+
SE planning addresses all programmatic and technical elements of the project to ensure a comprehensive and integrated plan for all of the project's technical aspects and should account for the full scope of technical activities, including system development and definition, [[Risk Management|risk management]], [[Quality Management|quality management]], [[Configuration Management|configuration management]], [[measurement]], [[Information Management|information management]], [[System Realization|production]], [[System Verification|verification and testing]], [[System Integration|integration]], [[System Validation|validation]], and [[System Deployment and Use|deployment]]. SE planning integrates all SE functions to ensure that plans, requirements, operational concepts, and architectures are consistent and feasible.
  
−
SE planning is accomplished by both the acquirer and supplier. The SE planning set of activities is performed in the context of the enterprise. Enterprise activities establish and identify relevant policies and procedures for managing and executing the project management and technical effort; identifying the management and technical tasks, their interdependencies, risks and opportunities; and providing estimates of needed resources/budgets. Plans are updated and refined throughout the development process based on status updates and evolving project requirements. (SEI 2007)
+
The scope of planning can vary from planning a specific task to developing a major technical plan. The integrated planning effort will determine what level of planning and accompanying documentation is appropriate for the project.  
 +
===Integration===
 +
The integration of each plan with other higher-level, peer, or subordinate plans is an essential part of SE planning. For the technical effort, the {{Term|Systems Engineering Plan (SEP) (glossary)|systems engineering management plan}} (SEMP), also frequently referred to as the {{Term|Systems Engineering Plan (SEP) (glossary)|systems engineering plan}} (SEP), is the highest-level technical plan. It is subordinate to the project plan and often has a number of subordinate technical plans providing detail on specific technical focus areas (INCOSE 2011, sec. 5.1.2.2; NASA 2007, appendix J).
  
 +
In U.S. defense work, the terms SEP and SEMP are not interchangeable. The SEP is a high-level plan that is made before the system acquisition and development begins. It is written by the government customer. The SEMP is the specific development plan written by the developer (or contractor). In this context, intent, and content of these documents are quite different. For example, a SEP will have an acquisition plan that would not be included in a SEMP. Figure 1 below shows the SEMP and integrated plans.
  
−
==SE Planning Process Overview==
+
[[File:semp_and_integrated_plans.png|thumb|400px|center|'''Figure 1. SEMP and Integrated Plans.''' (SEBoK Original)]]
−
Systems Engineering Planning is performed concurrently and collaboratively with project planning, and involves developing and integrating technical plans to achieve the technical project objectives within the resource constraints and [[Risk (glossary)|risk]] thresholds.  The planning needs to include the success-critical stakeholders to ensure that necessary tasks are defined with the right timing in the [[Life Cycle (glossary)|life cycle]] to manage acceptable risks levels and avoid costly omissions.  As indicated in (NASA December 2007, 1-360, Section 6.1), (Caltrans and USDOT 2005, 278, Section 3.4.2), (INCOSE 2010, Section 5.1), (DAU February 19, 2010, Section 4.5.1), and (USAF 2004, Chapter 4).
 
  
−
SE planning is intended to provide the following elements in a form that best meets the project usage preferences:
+
Task planning identifies the specific work products, deliverables, and success criteria for systems engineering efforts in support of integrated planning and project objectives. The success criteria are defined in terms of cost, schedule, and technical performance at identified project milestones. Detailed task planning identifies specific resource requirements (e.g., skills, equipment, facilities, and funding) as a function of time and project milestones.
−
*Definition of the project from a technical perspective.
 
−
*Definition or tailoring of engineering processes, practices, methods, and supporting enabling environments to be used to develop products or services, as well as transition and implementation of the products or services, as required by agreements.
 
−
*Definition of the technical organizational, personnel, and team functions and responsibilities, as well as all disciplines required during the project [[Life Cycle (glossary)|life cycle]].
 
−
*Input to the definition of the appropriate life cycle model or approach for the products or services.
 
−
*Definition and timing of technical reviews, product or service assessments, and control mechanisms across the life cycle, including the success criteria in terms of [[Cost (glossary)|cost]], schedule, and technical performance at identified project milestones.  
 
−
*Estimation of technical [[Cost (glossary)|cost]] and schedule based on the effort needed to meet the requirements, which becomes input to project cost and schedule planning.
 
−
*Determination of critical technologies and associated risks and actions needed to manage and transition the technologies.
 
−
*Identification of linkages to other project management efforts.
 
−
*Documentation of and commitment to the techncial planning
 
  
−
The figure below shows the SEMP and Integrated Plans.
+
SE planning is accomplished by both the {{Term|Acquirer (glossary)|acquirer}} and {{Term|Supplier (glossary)|supplier}} and the activities for SE planning are performed in the context of the respective enterprise. The activities establish and identify relevant policies and procedures for managing and executing the project management and technical effort, identifying the management and technical tasks, their interdependencies, risks, and opportunities, and providing estimates of needed resources/budgets. Plans are updated and refined throughout the development process based on status updates and evolving project requirements (SEI 2007).
−
 
 
−
 
 
−
[[File:semp_and_integrated_plans.png | 400px| center | SEMP and Integrated Plans ]]
 
−
 
 
−
<div style="text-align: center;">
 
−
'''SEMP and Integrated Plans
 
−
''' </div>
 
  
 
==Linkages to Other Systems Engineering Management Topics==
 
==Linkages to Other Systems Engineering Management Topics==
−
The project planning process is closely coupled with the [[Measurement]], [[Assessment and Control]], [[Decision Management]], and [[Risk Management]] processes.  
+
The project planning process is closely coupled with the [[Measurement|measurement]], [[Assessment and Control|assessment and control]], [[Decision Management|decision management]], and [[Risk Management|risk management]] processes.  
  
−
The [[Measurement]] process provides inputs for estimation models. Estimates from Planning are used in [[Decision Management]]. Systems engineering [[Assessment and Control]] processes use Planning results for setting milestones and assessing progress. [[Risk Management]] uses the Planning cost models, schedule estimates, and estimate uncertainty distributions to support quantitative risk analysis (as desired).
+
The measurement process provides inputs for estimation models. Estimates and other products from planning are used in decision management. SE assessment and control processes use planning results for setting milestones and assessing progress. Risk management uses the planning cost models, schedule estimates, and uncertainty distributions to support quantitative risk analysis (as desired).
  
−
Additionally, Planning needs to use the outputs from [[Assessment and Control]] and [[Risk Management]] to ensure corrective actions have been accounted for in planning future activities.   The planning may need to be updated based on results from technical reviews (from [[Assessment and Control]]), issues identified during the performance of [[Risk Management]] activities, or decisions made as a result of the decision management activities.  (INCOSE 2010, Section 6.1)
+
Additionally, planning needs to use the outputs from assessment and control as well as risk management to ensure corrective actions have been accounted for in planning future activities. The planning may need to be updated based on results from technical reviews (from assessment and control) addressing issues pertaining to: measurement, problems that were identified during the performance of risk management activities, or decisions made as a result of the decision management activities (INCOSE 2010, sec. 6.1).
  
 
==Practical Considerations==
 
==Practical Considerations==
  
 
===Pitfalls===
 
===Pitfalls===
−
Some of the key pitfalls encountered in planning and performing SE Planning are listed next.  
+
Some of the key pitfalls encountered in planning and performing SE planning are listed in Table 1.  
  
−
{|  
+
{|
−
|-
+
|+'''Table 1. Major Pitfalls with Planning.''' (SEBoK Original)
 
! Name
 
! Name
 
! Description
 
! Description
−
 
 
|-
 
|-
−
| Rushed Planning
+
| Incomplete and Rushed Planning
−
|  
+
| Inadequate SE planning causes significant adverse impacts on all other engineering activities.  Although one may be tempted to save time by rushing the planning, inadequate planning can create additional costs and interfere with the schedule due to planning omissions, lack of detail, lack of integration of efforts, infeasible cost and schedules, etc.  
−
*Inadequate SE planning causes significant adverse impacts on all other engineering activities.  Although it may be tempting to “save time” by rushing the planning, inadequate planning can create additional cost and schedule due to omissions in the planning, lack of integration of efforts, infeasible schedules, etc.  
 
−
 
 
 
|-
 
|-
 
| Inexperienced Staff
 
| Inexperienced Staff
−
|  
+
| Lack of highly experienced engineering staff members, especially in similar projects, will likely result in inadequate planning. Less experienced engineers are often assigned significant roles in the SE planning; however, they may not have the appropriate judgment to lay out realistic and achievable plans. It is essential to assign the SE planning tasks to those with a good amount of relevant experience.  
−
*Not using engineering staff members who are highly experienced, especially in similar projects, which will likely result in inadequate planning. Due to the number of concurrent and high-priority tasks during the start of a project, less experienced engineers are often assigned significant roles in the SE planning. Even though the more experienced engineering staff members are busy early in the project with many other responsibilities, it is essential to assign the SE planning tasks to those with relevant experience.  
 
−
 
 
 
|}
 
|}
  
 
===Good Practices===
 
===Good Practices===
−
Some good practices gathered from the references are below.
+
Some good practices gathered from the references are in Table 2.
  
−
{|  
+
{|
−
|-
+
|+'''Table 2. Proven Practices with Planning.''' (SEBoK Original)
 
! Name
 
! Name
 
! Description
 
! Description
 
|-
 
|-
 
| Use Multiple Disciplines
 
| Use Multiple Disciplines
−
|  
+
| Get technical resources from all disciplines involved in the planning process.
−
*Get technical resources from all disciplines involved in the planning process.
 
 
|-
 
|-
 
| Early Conflict Resolution
 
| Early Conflict Resolution
−
|
+
|Resolve schedule and resource conflicts early.
−
*Resolve schedule and resource conflicts early.
 
 
|-
 
|-
−
| Task independence
+
| Task Independence
−
|
+
|Tasks should be as independent as possible.
−
*Tasks should be as independent as possible.
 
−
 
 
 
|-
 
|-
 
| Define Interdependencies
 
| Define Interdependencies
−
|
+
|Define task interdependencies, using dependency networks or other approaches.  
−
*Develop dependency networks to define task interdependencies.
 
 
|-
 
|-
−
| [[Risk Management]]
+
| Risk Management
−
|
+
|Integrate risk management with the SE planning to identify areas that require special attention and/or trades.  
−
*Integrate [[Risk Management]] with the SE planning to identify areas that require special attention and/or trades.  
 
 
|-
 
|-
 
|Management Reserve  
 
|Management Reserve  
−
 
+
|The amount of management reserve should be based on the risk associated with the plan.
−
|
 
−
*The amount of management reserve should be based on the risk associated with the plan.
 
−
 
 
 
|-
 
|-
 
|Use Historical Data
 
|Use Historical Data
−
 
+
|Use historical data for estimates and adjust for differences in the project.
−
|
 
−
*Use historical data for estimates and adjust for differences of the project.
 
−
 
 
 
|-
 
|-
 
|Consider Lead Times
 
|Consider Lead Times
−
 
+
|Identify lead times and ensure that you account for them in the planning (e.g., the development of analytical tools).
−
|
 
−
*Identify lead times and account for them in the planning, e.g., development of analytical tools.
 
−
 
 
 
|-
 
|-
 
|Update Plans
 
|Update Plans
−
 
+
|Prepare to update plans as additional information becomes available or changes are needed.
−
|
 
−
*Prepare to update plans as additional information becomes available or changes are needed.
 
−
 
 
 
|-
 
|-
 
|Use IPDTs
 
|Use IPDTs
−
 
+
|An integrated product development team (IPDT) (or {{Term|Integrated Product Team (IPT) (glossary)|integrated product team (IPT)}}) is often useful to ensure adequate communication across the necessary disciplines, timely integration of all design considerations, as well as integration, testing, and consideration of the full range of risks that need to be addressed.  Although there are some issues that need to be managed with them, IPDTs tend to break down the communication and knowledge stovepipes that often exist.  
−
|
 
−
*An Integrated Product Development Team (IPDT) (or [[Integrated Product Team (IPT) (glossary)]]) is often useful to ensure adequate communications across the necessary disciplines, timely integration of all design considerations, as well as integration and test and consideration of the full range of risks that need to be addressed.  Although there are some issues that need to be managed with them, IPDTs tend to break down the communication and knowledge stovepipes that often already exist.  
 
−
 
 
 
|}
 
|}
  
−
Additional good practices can be found in (Caltrans and USDOT 2005, 278, Section 3.4.2)(NASA December 2007, 1-360, Section 6.1; INCOSE 2010, Section 5.1; USAF 2004, Chapter 4), and (ISO/IEC/IEEE 2009, Clause 6.1).
+
Additional good practices can be found in the ''[[Systems Engineering Guidebook for Intelligent Transportation Systems (ITS)]]'', ''[[NASA Systems Engineering Handbook]]'', the ''[[INCOSE Systems Engineering Handbook]]'', and ''[[ISO/IEC/IEEE 16326|Systems and Software Engineering - Life Cycle Processes - Project Management]]'' (Caltrans and USDOT 2005, 278; NASA December 2007, 1-360, sec. 6.1; INCOSE 2011, sec. 5.1; ISO/IEC/IEEE 2009, Clause 6.1).
−
 
 
−
==Glossary==
 
−
===Acronyms===
 
−
 
 
−
{|
 
−
|-
 
−
! Acronym
 
−
! Definition
 
−
 
 
−
|-
 
−
| IPDT
 
−
|
 
−
Integrated Product Development Team
 
−
 
 
−
|-
 
−
| SEMP
 
−
|
 
−
Systems Engineering Management Plan
 
−
 
 
−
|-
 
−
| SEP
 
−
|
 
−
Systems Engineering Plan
 
−
 
 
−
|}
 
  
 
==References==  
 
==References==  
  
 +
===Works Cited===
 +
Caltrans and USDOT. 2005. ''[[Systems Engineering Guidebook for Intelligent Transportation Systems (ITS)]],'' version 1.1. Sacramento, CA, USA: California Department of Transportation (Caltrans) Division of Reserach & Innovation/U.S. Department of Transportation (USDOT), SEG for ITS 1.1.
  
−
===Citations===
+
DAU. 2010. ''[[Defense Acquisition Guidebook (DAG)]].'' Ft. Belvoir, VA, USA: Defense Acquisition University (DAU)/U.S. Department of Defense, February 19.
−
 
 
−
Caltrans, and USDOT. 2005. [[Systems Engineering Guidebook for Intelligent Transportation Systems (ITS)]], version 1.1. Sacramento, CA, USA: California Department of Transportation (Caltrans) Division of Reserach & Innovation/U.S. Department of Transportation (USDOT), SEG for ITS 1.1.
 
−
 
 
−
DAU. February 19, 2010. [[Defense Acquisition Guidebook (DAG)]]. Ft. Belvoir, VA, USA: Defense Acquisition University (DAU)/U.S. Department of Defense.  
 
  
−
INCOSE. 2011. [[INCOSE Systems Engineering Handbook]]: A Guide for System Life Cycle Processes and Activities, version 3.2.1. San Diego, CA, USA: International Council on Systems Engineering (INCOSE), INCOSE-TP-2003-002-03.2.1.
+
INCOSE. 2012. ''[[INCOSE Systems Engineering Handbook]]: A Guide for System Life Cycle Processes and Activities.'' Version 3.2.2. San Diego, CA, USA: International Council on Systems Engineering (INCOSE), INCOSE-TP-2003-002-03.2.2.
  
−
ISO/IEC/IEEE. 2009. [[ISO/IEC/IEEE 16326|Systems and Software Engineering - Life Cycle Processes - Project Management]]. Geneva, Switzerland: International Organization for Standardization (ISO)/International Electronical Commission (IEC)/Institute of Electrical and Electronics Engineers (IEEE), [[ISO/IEC/IEEE 16326]]:2009(E).  
+
ISO/IEC/IEEE. 2009. ''[[ISO/IEC/IEEE 16326|Systems and Software Engineering - Life Cycle Processes - Project Management]]''. Geneva, Switzerland: International Organization for Standardization (ISO)/International Electrotechnical Commission (IEC)/Institute of Electrical and Electronics Engineers (IEEE), [[ISO/IEC/IEEE 16326]]:2009(E).  
  
−
NASA. December 2007. [[NASA Systems Engineering Handbook]]. Washington, D.C.: National Aeronautics and Space Administration (NASA), NASA/SP-2007-6105.  
+
NASA. 2007. ''[[NASA Systems Engineering Handbook]].'' Washington, D.C.: National Aeronautics and Space Administration (NASA), NASA/SP-2007-6105.  
  
−
SEI. 1995. A systems engineering capability maturity model, version 1.1. Pittsburgh, PA, USA: Software Engineering Institute (SEI)/Carnegie-Mellon University (CMU), CMU/SEI-95-MM-003.
+
SEI. 1995. ''A systems engineering capability maturity model.'' Version 1.1. Pittsburgh, PA, USA: Software Engineering Institute (SEI)/Carnegie-Mellon University (CMU), CMU/SEI-95-MM-003.
  
 
===Primary References===
 
===Primary References===
 +
Caltrans and USDOT. 2005. ''[[Systems Engineering Guidebook for Intelligent Transportation Systems (ITS)]],'' version 1.1. Sacramento, CA, USA: California Department of Transportation (Caltrans) Division of Reserach & Innovation/U.S. Department of Transportation (USDOT), SEG for ITS 1.1.
  
−
Caltrans, and USDOT. 2005. [[Systems Engineering Guidebook for Intelligent Transportation Systems (ITS)]], version 1.1. Sacramento, CA, USA: California Department of Transportation (Caltrans) Division of Reserach & Innovation/U.S. Department of Transportation (USDOT), SEG for ITS 1.1.  
+
DAU. 2010. ''[[Defense Acquisition Guidebook (DAG)]].'' Ft. Belvoir, VA, USA: Defense Acquisition University (DAU)/U.S. Department of Defense.  
  
−
DAU. February 19, 2010. [[Defense Acquisition Guidebook (DAG)]]. Ft. Belvoir, VA, USA: Defense Acquisition University (DAU)/U.S. Department of Defense.  
+
INCOSE. 2012. ''[[INCOSE Systems Engineering Handbook]]: A Guide for System Life Cycle Processes and Activities.'' Version 3.2.2. San Diego, CA, USA: International Council on Systems Engineering (INCOSE), INCOSE-TP-2003-002-03.2.2.
  
−
INCOSE. 2011. [[INCOSE Systems Engineering Handbook]]: A Guide for System Life Cycle Processes and Activities, version 3.2.1. San Diego, CA, USA: International Council on Systems Engineering (INCOSE), INCOSE-TP-2003-002-03.2.1.
+
ISO/IEC/IEEE. 2015. ''[[ISO/IEC/IEEE 15288|Systems and Software Engineering -- System Life Cycle Processes]]''. Geneva, Switzerland: International Organisation for Standardisation / International Electrotechnical Commissions / Institute of Electrical and Electronics Engineers. ISO/IEC/IEEE 15288:2015.  
  
−
ISO/IEC. 2008. [[ISO/IEC/IEEE 15288|Systems and Software Engineering - System Life Cycle Processes]]. Geneva, Switzerland: International Organization for Standardization (ISO)/International Electronical Commission (IEC), [[ISO/IEC/IEEE 15288|ISO/IEC/IEEE 15288]]:2008 (E).  
+
ISO/IEC/IEEE. 2009. ''[[ISO/IEC/IEEE 16326|Systems and Software Engineering - Life Cycle Processes - Project Management]]''. Geneva, Switzerland: International Organization for Standardization (ISO)/International Electrotechnical Commission (IEC)/Institute of Electrical and Electronics Engineers (IEEE), [[ISO/IEC/IEEE 16326]]:2009(E).
  
−
NASA. December 2007. [[NASA Systems Engineering Handbook]]. Washington, D.C.: National Aeronautics and Space Administration (NASA), NASA/SP-2007-6105.  
+
NASA. 2007. ''[[NASA Systems Engineering Handbook]].'' Washington, D.C., USA: National Aeronautics and Space Administration (NASA), NASA/SP-2007-6105.  
  
−
SEI. 1995. [[A Systems Engineering Capability Maturity Model]], version 1.1. Pittsburgh, PA, USA: Software Engineering Institute (SEI)/Carnegie-Mellon University (CMU), CMU/SEI-95-MM-003.  
+
SEI. 1995. ''[[A Systems Engineering Capability Maturity Model]],'' version 1.1. Pittsburgh, PA, USA: Software Engineering Institute (SEI)/Carnegie-Mellon University (CMU), CMU/SEI-95-MM-003.  
  
−
SEI. 2007. [[Capability Maturity Model Integrated (CMMI) for Development]], version 1.2, measurement and analysis process area. Pittsburgh, PA, USA: Software Engineering Institute (SEI)/Carnegie Mellon University (CMU).
+
SEI. 2007. ''[[Capability Maturity Model Integrated (CMMI) for Development]],'' version 1.2, measurement and analysis process area. Pittsburgh, PA, USA: Software Engineering Institute (SEI)/Carnegie Mellon University (CMU).
  
 
===Additional References===
 
===Additional References===
 +
Boehm, B., C. Abts, A.W. Brown, S. Chulani, B.K. Clark, E. Horowitz, R. Madachy, D.J. Reifer, B. Steece. 2000. ''Software Cost Estimation with COCOMO II''. Englewood Cliffs, NJ, USA: Prentice Hall
  
−
ISO/IEC/IEEE. 2009. [[ISO/IEC/IEEE 16326|Systems and Software Engineering - Life Cycle Processes - Project Management]]. Geneva, Switzerland: International Organization for Standardization (ISO)/International Electronical Commission (IEC)/Institute of Electrical and Electronics Engineers (IEEE), [[ISO/IEC/IEEE 16326]]:2009(E).  
+
DeMarco, T. and T. Lister. 2003. ''Waltzing with Bears; Managing Risks on Software Projects.''  New York, NY, USA: Dorset House.
−
----
 
−
====Article Discussion====
 
  
−
Brian Wells Comments: Materials and references are very good.
+
ISO/IEC/IEEE. 2009. ''Systems and Software Engineering - Life Cycle Processes - Project Management.'' Geneva, Switzerland: International Organization for Standardization (ISO)/International Electrotechnical Commission (IEC)/Institute of Electrical and Electronics Engineers (IEEE), ISO/IEC/IEEE 16326:2009(E).
−
Write up is very good.
 
  
−
A SEMP and a SEP are not the same and the author should not say this in the article. SEP is a high level plan made before the system acquisition and development begin.  It is written by the government customer.  The SEMP is the specific development plan written by the developer (or contractor). The intent and content are quite different.  SEP will have an acquisition plan, for example, that would not be included in a SEMP. (I can provide additional SEP and SEMP references if necessary.)
+
Valerdi, R. 2008.  ''The Constructive Systems Engineering Cost Model (COSYSMO): Quantifying the Costs of Systems Engineering Effort in Complex Systems''. Saarbrücken,Germany: VDM Verlag Dr. Muller
−
 
+
----
−
Figure that shows content of a SEMP should be reconfigured to fit the page better.
+
<center>[[Systems Engineering Management|< Previous Article]]  |  [[Systems Engineering and Management|Parent Article]]  |  [[Assessment and Control|Next Article >]]</center>
−
 
 
−
Has the author looked into and considered what is used in commercial SE development?
 
  
−
[[{{TALKPAGENAME}}|[Go to discussion page]]]
+
<center>'''SEBoK v. 2.10, released 06 May 2024'''</center>
−
<center>[[Systems Engineering Management|<- Previous Article]] | [[Systems Engineering Management|Parent Article]] | [[Assessment and Control|Next Article ->]]</center>
 
  
−
==Signatures==
 
 
[[Category: Part 3]][[Category:Topic]]
 
[[Category: Part 3]][[Category:Topic]]
 +
[[Category:Systems Engineering Management]]

Latest revision as of 23:20, 2 May 2024

Lead Authors: Ray Madachy, Garry Roedler, Brian Wells

Planning is an important aspect of systems engineering management (SEM). Systems engineeringSystems engineering (SE) planning is performed concurrently and collaboratively with project planning. It involves developing and integrating technical plans to achieve the technical project objectives within the resource constraints and riskrisk thresholds. The planning involves the success-critical stakeholders to ensure that necessary tasks are defined with the right timing in the life cyclelife cycle in order to manage acceptable risks levels, meet schedules, and avoid costly omissions.

SE Planning Process Overview

SE planning provides the following elements:

  • Definition of the projectproject from a technical perspective.
  • Definition or tailoring of engineering processes, practices, methods, and supporting enabling environments to be used to develop products or services, as well as plans for transition and implementation of the products or services, as required by agreements.
  • Definition of the technical organizational, personnel, and team functions and responsibilities, as well as all disciplines required during the project life cycle.
  • Definition of the appropriate life cycle modellife cycle model or approach for the productsproducts or servicesservices.
  • Definition and timing of technical reviews, product or service assessments, and control mechanisms across the life cycle, including the success criteria such as costcost, schedule, and technical performance at identified project milestones.
  • Estimation of technical cost and schedule based on the effort needed to meet the requirements; this estimation becomes input to project cost and schedule planning.
  • Determination of critical technologies, as well as the associated risks and actions needed to manage and transition these technologies.
  • Identification of linkages to other project management efforts.
  • Documentation of and commitment to the technical planning.

Scope

SE planning begins with analyzing the scopescope of technical work to be performed and gaining an understanding the constraints, risks, and objectives that define and bound the solution space for the product or service. The planning includes estimating the size of the work products, establishing a schedule (or integrating the technical tasks into the project schedule), identification of risks, and negotiating commitments. Iteration of these planning tasks may be necessary to establish a balanced plan with respect to cost, schedule, technical performance, and quality. The planning continues to evolve with each successive life cycle phase of the project (NASA 2007, 1-360; SEI 1995, 12).

SE planning addresses all programmatic and technical elements of the project to ensure a comprehensive and integrated plan for all of the project's technical aspects and should account for the full scope of technical activities, including system development and definition, risk management, quality management, configuration management, measurement, information management, production, verification and testing, integration, validation, and deployment. SE planning integrates all SE functions to ensure that plans, requirements, operational concepts, and architectures are consistent and feasible.

The scope of planning can vary from planning a specific task to developing a major technical plan. The integrated planning effort will determine what level of planning and accompanying documentation is appropriate for the project.

Integration

The integration of each plan with other higher-level, peer, or subordinate plans is an essential part of SE planning. For the technical effort, the systems engineering management plansystems engineering management plan (SEMP), also frequently referred to as the systems engineering plansystems engineering plan (SEP), is the highest-level technical plan. It is subordinate to the project plan and often has a number of subordinate technical plans providing detail on specific technical focus areas (INCOSE 2011, sec. 5.1.2.2; NASA 2007, appendix J).

In U.S. defense work, the terms SEP and SEMP are not interchangeable. The SEP is a high-level plan that is made before the system acquisition and development begins. It is written by the government customer. The SEMP is the specific development plan written by the developer (or contractor). In this context, intent, and content of these documents are quite different. For example, a SEP will have an acquisition plan that would not be included in a SEMP. Figure 1 below shows the SEMP and integrated plans.

Figure 1. SEMP and Integrated Plans. (SEBoK Original)

Task planning identifies the specific work products, deliverables, and success criteria for systems engineering efforts in support of integrated planning and project objectives. The success criteria are defined in terms of cost, schedule, and technical performance at identified project milestones. Detailed task planning identifies specific resource requirements (e.g., skills, equipment, facilities, and funding) as a function of time and project milestones.

SE planning is accomplished by both the acquireracquirer and suppliersupplier and the activities for SE planning are performed in the context of the respective enterprise. The activities establish and identify relevant policies and procedures for managing and executing the project management and technical effort, identifying the management and technical tasks, their interdependencies, risks, and opportunities, and providing estimates of needed resources/budgets. Plans are updated and refined throughout the development process based on status updates and evolving project requirements (SEI 2007).

Linkages to Other Systems Engineering Management Topics

The project planning process is closely coupled with the measurement, assessment and control, decision management, and risk management processes.

The measurement process provides inputs for estimation models. Estimates and other products from planning are used in decision management. SE assessment and control processes use planning results for setting milestones and assessing progress. Risk management uses the planning cost models, schedule estimates, and uncertainty distributions to support quantitative risk analysis (as desired).

Additionally, planning needs to use the outputs from assessment and control as well as risk management to ensure corrective actions have been accounted for in planning future activities. The planning may need to be updated based on results from technical reviews (from assessment and control) addressing issues pertaining to: measurement, problems that were identified during the performance of risk management activities, or decisions made as a result of the decision management activities (INCOSE 2010, sec. 6.1).

Practical Considerations

Pitfalls

Some of the key pitfalls encountered in planning and performing SE planning are listed in Table 1.

Table 1. Major Pitfalls with Planning. (SEBoK Original)
Name Description
Incomplete and Rushed Planning Inadequate SE planning causes significant adverse impacts on all other engineering activities. Although one may be tempted to save time by rushing the planning, inadequate planning can create additional costs and interfere with the schedule due to planning omissions, lack of detail, lack of integration of efforts, infeasible cost and schedules, etc.
Inexperienced Staff Lack of highly experienced engineering staff members, especially in similar projects, will likely result in inadequate planning. Less experienced engineers are often assigned significant roles in the SE planning; however, they may not have the appropriate judgment to lay out realistic and achievable plans. It is essential to assign the SE planning tasks to those with a good amount of relevant experience.

Good Practices

Some good practices gathered from the references are in Table 2.

Table 2. Proven Practices with Planning. (SEBoK Original)
Name Description
Use Multiple Disciplines Get technical resources from all disciplines involved in the planning process.
Early Conflict Resolution Resolve schedule and resource conflicts early.
Task Independence Tasks should be as independent as possible.
Define Interdependencies Define task interdependencies, using dependency networks or other approaches.
Risk Management Integrate risk management with the SE planning to identify areas that require special attention and/or trades.
Management Reserve The amount of management reserve should be based on the risk associated with the plan.
Use Historical Data Use historical data for estimates and adjust for differences in the project.
Consider Lead Times Identify lead times and ensure that you account for them in the planning (e.g., the development of analytical tools).
Update Plans Prepare to update plans as additional information becomes available or changes are needed.
Use IPDTs An integrated product development team (IPDT) (or integrated product team (IPT)integrated product team (IPT)) is often useful to ensure adequate communication across the necessary disciplines, timely integration of all design considerations, as well as integration, testing, and consideration of the full range of risks that need to be addressed. Although there are some issues that need to be managed with them, IPDTs tend to break down the communication and knowledge stovepipes that often exist.

Additional good practices can be found in the Systems Engineering Guidebook for Intelligent Transportation Systems (ITS), NASA Systems Engineering Handbook, the INCOSE Systems Engineering Handbook, and Systems and Software Engineering - Life Cycle Processes - Project Management (Caltrans and USDOT 2005, 278; NASA December 2007, 1-360, sec. 6.1; INCOSE 2011, sec. 5.1; ISO/IEC/IEEE 2009, Clause 6.1).

References

Works Cited

Caltrans and USDOT. 2005. Systems Engineering Guidebook for Intelligent Transportation Systems (ITS), version 1.1. Sacramento, CA, USA: California Department of Transportation (Caltrans) Division of Reserach & Innovation/U.S. Department of Transportation (USDOT), SEG for ITS 1.1.

DAU. 2010. Defense Acquisition Guidebook (DAG). Ft. Belvoir, VA, USA: Defense Acquisition University (DAU)/U.S. Department of Defense, February 19.

INCOSE. 2012. INCOSE Systems Engineering Handbook: A Guide for System Life Cycle Processes and Activities. Version 3.2.2. San Diego, CA, USA: International Council on Systems Engineering (INCOSE), INCOSE-TP-2003-002-03.2.2.

ISO/IEC/IEEE. 2009. Systems and Software Engineering - Life Cycle Processes - Project Management. Geneva, Switzerland: International Organization for Standardization (ISO)/International Electrotechnical Commission (IEC)/Institute of Electrical and Electronics Engineers (IEEE), ISO/IEC/IEEE 16326:2009(E).

NASA. 2007. NASA Systems Engineering Handbook. Washington, D.C.: National Aeronautics and Space Administration (NASA), NASA/SP-2007-6105.

SEI. 1995. A systems engineering capability maturity model. Version 1.1. Pittsburgh, PA, USA: Software Engineering Institute (SEI)/Carnegie-Mellon University (CMU), CMU/SEI-95-MM-003.

Primary References

Caltrans and USDOT. 2005. Systems Engineering Guidebook for Intelligent Transportation Systems (ITS), version 1.1. Sacramento, CA, USA: California Department of Transportation (Caltrans) Division of Reserach & Innovation/U.S. Department of Transportation (USDOT), SEG for ITS 1.1.

DAU. 2010. Defense Acquisition Guidebook (DAG). Ft. Belvoir, VA, USA: Defense Acquisition University (DAU)/U.S. Department of Defense.

INCOSE. 2012. INCOSE Systems Engineering Handbook: A Guide for System Life Cycle Processes and Activities. Version 3.2.2. San Diego, CA, USA: International Council on Systems Engineering (INCOSE), INCOSE-TP-2003-002-03.2.2.

ISO/IEC/IEEE. 2015. Systems and Software Engineering -- System Life Cycle Processes. Geneva, Switzerland: International Organisation for Standardisation / International Electrotechnical Commissions / Institute of Electrical and Electronics Engineers. ISO/IEC/IEEE 15288:2015.

ISO/IEC/IEEE. 2009. Systems and Software Engineering - Life Cycle Processes - Project Management. Geneva, Switzerland: International Organization for Standardization (ISO)/International Electrotechnical Commission (IEC)/Institute of Electrical and Electronics Engineers (IEEE), ISO/IEC/IEEE 16326:2009(E).

NASA. 2007. NASA Systems Engineering Handbook. Washington, D.C., USA: National Aeronautics and Space Administration (NASA), NASA/SP-2007-6105.

SEI. 1995. A Systems Engineering Capability Maturity Model, version 1.1. Pittsburgh, PA, USA: Software Engineering Institute (SEI)/Carnegie-Mellon University (CMU), CMU/SEI-95-MM-003.

SEI. 2007. Capability Maturity Model Integrated (CMMI) for Development, version 1.2, measurement and analysis process area. Pittsburgh, PA, USA: Software Engineering Institute (SEI)/Carnegie Mellon University (CMU).

Additional References

Boehm, B., C. Abts, A.W. Brown, S. Chulani, B.K. Clark, E. Horowitz, R. Madachy, D.J. Reifer, B. Steece. 2000. Software Cost Estimation with COCOMO II. Englewood Cliffs, NJ, USA: Prentice Hall

DeMarco, T. and T. Lister. 2003. Waltzing with Bears; Managing Risks on Software Projects. New York, NY, USA: Dorset House.

ISO/IEC/IEEE. 2009. Systems and Software Engineering - Life Cycle Processes - Project Management. Geneva, Switzerland: International Organization for Standardization (ISO)/International Electrotechnical Commission (IEC)/Institute of Electrical and Electronics Engineers (IEEE), ISO/IEC/IEEE 16326:2009(E).

Valerdi, R. 2008. The Constructive Systems Engineering Cost Model (COSYSMO): Quantifying the Costs of Systems Engineering Effort in Complex Systems. Saarbrücken,Germany: VDM Verlag Dr. Muller

< Previous Article | Parent Article | Next Article >
SEBoK v. 2.10, released 06 May 2024
Retrieved from "https://sandbox.sebokwiki.org/index.php?title=Technical_Planning&oldid=71893"