Difference between revisions of "The Nature of Project Management"

From SEBoK
Jump to navigation Jump to search
Line 1: Line 1:
While the ''Project Management Body of Knowledge (PMBOK™)'' provides an overview of project management for those seeking [[Acronyms|PMI]] certification, Fairley (2009) and Forsberg (2005) suggest another way to characterize the important aspects of project management:
+
While the ''Project Management Body of Knowledge (PMBOK™)'' provides an overview of project management for those seeking PMI certification, Fairley (2009) and Forsberg (2005) suggest another way to characterize the important aspects of project management:
  
 
*Planning and Estimating
 
*Planning and Estimating

Revision as of 04:56, 29 November 2012

While the Project Management Body of Knowledge (PMBOK™) provides an overview of project management for those seeking PMI certification, Fairley (2009) and Forsberg (2005) suggest another way to characterize the important aspects of project management:

  • Planning and Estimating
  • Measuring and Controlling
  • Leading and Directing
  • Managing Risk

Introduction

Project managers and systems engineers are both concerned with management issues such as planning, measuring and controlling, leading, directing, and managing risk. In the case of project managers, the project attributes to be managed include project plans; estimates; schedule; budget; project structure; staffing; resources; infrastructure; and risk factors. Product attributes managed by systems engineers include items such as requirements allocation and flow-down; system architecture; structure of and interactions among technical teams; specialty engineering; integration ; verification; and validation.

The exact allocation of the SE and PM duties depend on many factors, such as customer and stakeholder interactions, organizational structure of the parent organization, and relationships with affiliate contractors and subcontractors. (See the article on The Influence of Project Structure and Governance on Systems Engineering and Project Management Relationships in this KA.)

Planning and Estimating

Planning a project involves providing answers to the who, what, where, when, and why of every project:

  • Who: Addresses staffing issues (competencies, numbers of staff, communication and coordination)
  • What: Addresses the scope of activities
  • Where: Addresses issues of locale (local, geographically distributed)
  • When: Addresses scheduling issues
  • Why: Addresses rationale for conducting a project

Guidance for developing project plans can be found in INCOSE (2012), NASA (2007), and ISO/IEC/IEEE Standard 16326:2009. It is often observed that communication and coordination among stakeholders during project planning are equally as important as (and sometimes more important than) the documented plan that is produced.

In defense work, event-driven integrated master plans and time-driven integrated master schedules are planning products. Chapter 11 of the Defense Acquisition Guidebook provides details (DAU 2010).

Estimating

Estimation is an important element of planning. An estimate is a projection from past to future, adjusted to account for differences between past and future. Estimation techniques include analogy, rule of thumb, expert judgment, and use of parametric models such as the PRICE model for hardware, COCOMO for software projects and COSYSMO for systems projects (Stewart 1990, Boehm et al 2000, Valerdi 2008).

Entities estimated include (but are not limited to) schedule; cost; performance; and risk.

Systems engineering contributes to project estimation efforts by ensuring that

  • the overall system life cycle is understood;
  • dependencies on other systems and organizations are identified;
  • the logical dependencies during development are identified; and
  • resources and key skills are identified and planned.

Additionally, high-level system architecture and risk assessment provide the basis for both the work breakdown structure and the organizational breakdown structure.

Measuring and Controlling

Measuring and controlling are the key elements of executing a project. Measurement includes collecting measures for work products and work processes. For example, determining the level of coverage of requirements in a design specification can be assessed through review, analysis, prototyping, and traceability. Effort and schedule expended on the work processes can be measured and compared to estimates; earned value tracking can be used for this purpose. Controlling is concerned with analyzing measurement data and implementing corrective actions when actual status does not align with planned status.

Systems engineers may be responsible for managing all technical aspects of project execution, or they may serve as staff support for the project manager or project management office. Organizational relationships between systems engineers and project managers are presented in Team Capability. Other organizational considerations for the relationships between systems engineering and project management are covered in the Enabling Systems Engineering knowledge area.

Additional information on measurement and control of technical factors can be found in the Measurement and Assessment and Control articles in Part 3: Systems Engineering and Management.

Leading and Directing

Leading and directing requires communication and coordination among all project stakeholders, both internal and external. Systems engineers may be responsible for managing all technical aspects of project execution, or they may serve as staff support for the project manager or project management office. Organizational relationships between systems engineers and project managers are presented in the article Team Capability in Part 5. Other organizational considerations for the relationships between systems engineering and project management are discussed in Part 5: Enabling Systems Engineering.

Managing Risk

Risk management is concerned with identifying and mitigating potential problems before they become real problems. Systems engineering projects are, by nature, high-risk endeavors because of the many unknowns and uncertainties that are inherent in projects. Because new risk factors typically emerge during a project, ongoing continuous risk management is an important activity for both systems engineers and project managers.

Potential and actual problems may exist within every aspect of a project. Systems engineers are typically concerned with technical risk and project managers with programmatic risk. Sometimes, technical risk factors are identified and confronted by systems engineers and programmatic risk factors are identified and confronted by project managers without adequate communication between them. In these cases, appropriate tradeoffs among requirements, schedule, budget, infrastructure, and technology may not be made, which creates additional risk for the successful outcome of a project.

In the last ten years, there has been an increasing interest in opportunity management as the converse of risk management. Hillson(2003), Olsson (2007), and Chapman and Ward (2003) provide highly cited introductions.

Additional information on risk management for systems engineering projects can be found in the Risk Management article in Part 3: Systems Engineering and Management.

References

Works Cited

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

Chapman, C., and S. Ward. 2003. Project Risk Management: Processes, Techniques and Insights. Chichester, West Sussex, England: John Wiley and Sons.

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

Fairley, R.E. 2009. Managing and Leading Software Projects. Hoboken NJ, USA: John Wiley & Sons.

Forsberg, K., H. Mooz, and H. Cotterman. 2005. Visualizing Project Management. Hoboken, NJ, USA: John Wiley and Sons.

Hillson, David. 2003. Effective Opportunity Management for Projects: Exploiting Positive Risk. Boca Raton, FL, USA: CRC Press.

INCOSE. 2012. 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 Electronical Commission (IEC)/Institute of Electrical and Electronics Engineers (IEEE), ISO/IEC/IEEE 16326:2009(E).

NASA. 2007. Systems Engineering Handbook." Washington, DC,USA: National Aeronautics and Space Administration. Olsson, Rolf. 2007. In search of opportunity management: Is the risk management process enough? International Journal of Project Management, 25 (8), 745–752, 2011.

Stewart, Rodney. 1990. Cost estimating. New York, NY, USA: Wiley.

Valerdi, R. The Constructive Systems Engineering Cost Model (COSYSMO): Quantifying the Costs of Systems Engineering Effort. Saarbrucken, Germany: VDM Verlag.

Primary References

Fairley, R.E. 2009. Managing and Leading Software Projects. Hoboken, NJ, USA: John Wiley & Sons.

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

Additional References

Blanchard, B. 2008. System Engineering Management. Hoboken, NJ, USA: John Wiley & Sons.

Kerzner, Harold. 2003. Project Management: A Systems Approach to Planning, Scheduling, and Controlling. 8th Ed. Hoboken, NJ, USA: John Wiley & Sons.

Martin, J. 1997. Systems Engineering Guidebook: A Process for Developing Systems and Products. London, UK: Taylor and Francis Group CRC-Press, LLC.


< Previous Article | Parent Article | Next Article >
SEBoK v. 1.9.1 released 30 September 2018

SEBoK Discussion

Please provide your comments and feedback on the SEBoK below. You will need to log in to DISQUS using an existing account (e.g. Yahoo, Google, Facebook, Twitter, etc.) or create a DISQUS account. Simply type your comment in the text field below and DISQUS will guide you through the login or registration steps. Feedback will be archived and used for future updates to the SEBoK. If you provided a comment that is no longer listed, that comment has been adjudicated. You can view adjudication for comments submitted prior to SEBoK v. 1.0 at SEBoK Review and Adjudication. Later comments are addressed and changes are summarized in the Letter from the Editor and Acknowledgements and Release History.

If you would like to provide edits on this article, recommend new content, or make comments on the SEBoK as a whole, please see the SEBoK Sandbox.

blog comments powered by Disqus