Difference between revisions of "Relationships between Systems Engineering and Project Management"

From SEBoK
Jump to navigation Jump to search
Line 1: Line 1:
The methods, tools, and techniques of project management can be recursively applied to managing the technical aspects of a project.  Technical work activities must be planned, organized, staffed, controlled, and directed; the what, who, when, where, how, and why questions must be answered; work activities must be planned and estimated, measured and controlled, led and directed, and risk must be managed.  
+
The scope of systems engineering as described in the SEBOK, CMMI, and other sources, and the scope of project management as described in the PMBOK, CMMI, and other sources have a great deal of overlap as shown in Figure 1  
  
==The Systems Engineering Management Plan (SEMP)==
+
The systems engineering management plan (SEMP) is an important element of systems engineering.  According to NASA (2007): "The SEMP is the rule book that describes to all participants how the project will be technically managed" (NASA 2007, p. 120). Appendix J of the NASA Systems Engineering Handbook (NASA 2007) provides a checklist of items that should be included in an SEMP, as needed  [[http://education.ksc.nasa.gov/esmdspacegrant/Documents/NASA%20SP-2007-6105%20Rev%201%20Final%2031Dec2007.pdf]]:
+
<center>'''Figure 1 – Overlap of PM and SE'''</center>
  
*Purpose and Scope of the SEMP
+
These sources describe the importance of understanding the scope of the work at hand, how to plan for critical activities, how to manage efforts while reducing risk, and how to successfully deliver value to a customer.  The systems engineer working on a project plans, monitors, confronts risk, and delivers the technical aspects of the project, while the project manager is concerned with the same kinds of activities for the overall project.  Because of these shared concerns, there is room for confusion and tension between the roles of the project manager and the systems engineer on a given project.  As shown in Figure 2, on some projects, there is no overlap in responsibility.  On other projects, there could be shared responsibilities for planning and managing activities, and in some cases, particularly for smaller projects, the project manager may also be the lead technical member of the team performing both roles of project manager and systems engineer.
*Applicable Documents
 
*Technical Summary
 
*System Description
 
*System Structure
 
*Product Integration
 
*Boundary of Technical Effort
 
*Cross References
 
*Technical Effort Integration, including
 
**Concurrent engineering,
 
**The activity phasing of specialty engineering,
 
**The participation of specialty disciplines,
 
**The involvement of specialty disciplines,
 
**The role and responsibility of specialty disciplines,
 
**The participation of specialty disciplines in system decomposition and definition,
 
**The role of specialty disciplines in verification and validation,
 
**Reliability,
 
**Maintainability,
 
**Quality assurance,
 
**Integrated logistics,
 
**Human engineering,
 
**Safety,
 
**Producibility, and
 
**Survivability/vulnerability.
 
*Responsibility and Authority
 
*Contractor Integration
 
*Support Integration
 
*Technical Process Integration
 
*Technology Insertion
 
*Engineering Methods and Tools
 
*Specialty Engineering
 
*Integration with the Project Plan and Technical Resource Allocation
 
*Waivers
 
*Appendices
 
**including plan templates
 
*References
 
  
Some systems engineers become specialists in systems engineering project management.
+
 +
<center>'''Figure 2 – Overlap of project roles'''</center>
 +
 
 +
Regardless of how the roles are divvied up on a given project, the best way to reduce confusion is to explicitly describe the roles and responsibilities of the project manager and the systems engineer as well as other key team members.  The Project Management Plan (PMP) and the Systems Engineering Management Plan (SEMP) are key documents used to define the processes and methodologies the project will employ to build and deliver a product or service. 
 +
The PMP is the master planning document for the project.  It describes all activities, including technical activities, to be integrated and controlled during the life of the program.  The SEMP is the master planning document for the systems engineering technical elements.  It defines SE processes and methodologies used on the project and the relationship of SE activities to other project activities.  The SEMP must be consistent with, and evolve in concert with, the PMP.  In addition, some customers have technical management plans and expectations that the project’s SEMP integrate with customer plans and activities.  In the U.S. Department of Defense, most government project teams have a Systems Engineering Plan (SEP) with an expectation that the contractor’s SEMP integrate and remain consistent with customer technical activities.  In cases where the project is developing a component of a larger system, the component project’s SEMP will need to integrate with the overall project’s SEMP.
 +
 
 +
Given the emphasis within SE references on the importance of planning and managing the technical aspects of the project, an effective systems engineer will need to have a strong foundation in management skills and experience in addition to having strong technical depth.  From developing and defending basis of estimates, to planning and monitoring technical activities, to identifying and mitigating technical risk, to identifying and including relevant stakeholders during the life of the project, the systems engineer becomes a key member of the project’s management and leadership team.
  
==Future Version 1.0 Additions==
 
This article is not complete. Version 1.0 of the SEBoK will note in more detail the similarities and differences between project management and systems engineering. Topics being considered are: TBD.
 
  
 
==References==  
 
==References==  
  
 
===Citations===
 
===Citations===
NASA. 2007. ''[[NASA Systems Engineering Handbook|Systems Engineering Handbook]],'' Revision 1. Washington, DC, USA: National Aeronautics and Space Administration (NASA). NASA/SP-2007-6105.
+
CMMI. 2011. ''‪CMMI® for Development: Guidelines for Process Integration and Product Improvement''. Old Tappan, New Jersey; Pearson Education.
 +
 
 +
PMI. 2008. ''A Guide to the Project Management Body of Knowledge'' (PMBOK® GUIDE)-Fourth Edition. Newtown Square, Pennsylvania; Project Management Institute, Inc.  
  
 
===Primary References===
 
===Primary References===
Fairley, R.E. 2009. ''[[Managing and Leading Software Projects]].'' Hoboken, NJ, USA: John Wiley & Sons.
+
CMMI. 2011. ''[[‪CMMI for Development]]: Guidelines for Process Integration and Product Improvement''. Old Tappan, New Jersey; Pearson Education.
 
 
NASA. 2007. ''[[NASA Systems Engineering Handbook|Systems Engineering Handbook]],'' Revision 1. Washington, DC, USA: National Aeronautics and Space Administration (NASA). NASA/SP-2007-6105.
 
  
 
PMI 2008. ''[[A Guide to the Project Management Body of Knowledge]],'' 4th ed. Newtown Square, PA, USA: Project Management Institute (PMI).
 
PMI 2008. ''[[A Guide to the Project Management Body of Knowledge]],'' 4th ed. Newtown Square, PA, USA: Project Management Institute (PMI).
  
 
===Additional References===
 
===Additional References===
Blanchard, B. 2008. ''System Engineering Management.'' Hoboken NJ, USA: John Wiley & Sons.
+
NASA. 2007. ''Systems Engineering Handbook'', Revision 1. Washington, DC, USA: National Aeronautics and Space Administration (NASA). NASA/SP-2007-6105.  
 +
 
 
----
 
----
 
<center>[[An Overview of Project Management|<- Previous Article]] | [[Systems Engineering and Project Management|Parent Article]] | [[Systems Engineering and Procurement/Acquisition|Next Article ->]]</center>
 
<center>[[An Overview of Project Management|<- Previous Article]] | [[Systems Engineering and Project Management|Parent Article]] | [[Systems Engineering and Procurement/Acquisition|Next Article ->]]</center>

Revision as of 16:54, 8 February 2012

The scope of systems engineering as described in the SEBOK, CMMI, and other sources, and the scope of project management as described in the PMBOK, CMMI, and other sources have a great deal of overlap as shown in Figure 1


Figure 1 – Overlap of PM and SE

These sources describe the importance of understanding the scope of the work at hand, how to plan for critical activities, how to manage efforts while reducing risk, and how to successfully deliver value to a customer. The systems engineer working on a project plans, monitors, confronts risk, and delivers the technical aspects of the project, while the project manager is concerned with the same kinds of activities for the overall project. Because of these shared concerns, there is room for confusion and tension between the roles of the project manager and the systems engineer on a given project. As shown in Figure 2, on some projects, there is no overlap in responsibility. On other projects, there could be shared responsibilities for planning and managing activities, and in some cases, particularly for smaller projects, the project manager may also be the lead technical member of the team performing both roles of project manager and systems engineer.


Figure 2 – Overlap of project roles

Regardless of how the roles are divvied up on a given project, the best way to reduce confusion is to explicitly describe the roles and responsibilities of the project manager and the systems engineer as well as other key team members. The Project Management Plan (PMP) and the Systems Engineering Management Plan (SEMP) are key documents used to define the processes and methodologies the project will employ to build and deliver a product or service. The PMP is the master planning document for the project. It describes all activities, including technical activities, to be integrated and controlled during the life of the program. The SEMP is the master planning document for the systems engineering technical elements. It defines SE processes and methodologies used on the project and the relationship of SE activities to other project activities. The SEMP must be consistent with, and evolve in concert with, the PMP. In addition, some customers have technical management plans and expectations that the project’s SEMP integrate with customer plans and activities. In the U.S. Department of Defense, most government project teams have a Systems Engineering Plan (SEP) with an expectation that the contractor’s SEMP integrate and remain consistent with customer technical activities. In cases where the project is developing a component of a larger system, the component project’s SEMP will need to integrate with the overall project’s SEMP.

Given the emphasis within SE references on the importance of planning and managing the technical aspects of the project, an effective systems engineer will need to have a strong foundation in management skills and experience in addition to having strong technical depth. From developing and defending basis of estimates, to planning and monitoring technical activities, to identifying and mitigating technical risk, to identifying and including relevant stakeholders during the life of the project, the systems engineer becomes a key member of the project’s management and leadership team.


References

Citations

CMMI. 2011. ‪CMMI® for Development: Guidelines for Process Integration and Product Improvement‬. Old Tappan, New Jersey; Pearson Education.

PMI. 2008. A Guide to the Project Management Body of Knowledge (PMBOK® GUIDE)-Fourth Edition. Newtown Square, Pennsylvania; Project Management Institute, Inc.

Primary References

CMMI. 2011. ‪CMMI for Development: Guidelines for Process Integration and Product Improvement‬. Old Tappan, New Jersey; Pearson Education.

PMI 2008. A Guide to the Project Management Body of Knowledge, 4th ed. Newtown Square, PA, USA: Project Management Institute (PMI).

Additional References

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


<- Previous Article | Parent Article | Next Article ->