Systems Engineering and Project Management

The goal of project management is to plan and coordinate the work activities needed to deliver a satisfactory product, service, or enterprise endeavor within the constraints of schedule, budget, resources, infrastructure, and available technology. There are many ways to categorize the elements of project management. According to Section 1.3 of the PMBOK© Guide – Fourth Edition, project management is:

accomplished through the appropriate application and integration of the 42 logically grouped project management processes comprising the 5 process groups. These 5 process groups are:

• Initiating,
• Planning,
• Executing,
• Monitoring and Controlling, and
• Closing.

The scope of project management encompasses the total set of concerns that contribute to successful outcomes. This knowledge area provides an overview of project management and describes the relationships between project management, systems engineering, and systems engineering management.

An Overview of Project Management

For purposes of exposition, project management will be characterized as follows:

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

Planning a project involves providing answers to the questions: who? what? where? when? and why?. Who addresses the staffing issue; What the scope of activities; Where the issues of locale (local, geographically distributed); When addresses scheduling; and Why addresses the rationale for a project [Boehm reference]. Standards for project plans include xxx. It is often observed that communication and interactions during the planning process are equally important, and sometimes more important than the documented plan that is produced.

Estimation is an important element of planning. An estimate is a projection from past to future, adjusted to account for difference between past and future. Estimation techniques include analogy, rule of thumb, expert judgment, and use of parametric models such as COSYSMO [references].

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 determined by reviews, analysis, prototyping, and traceability. Effort and schedule expended on these work processes also can be measured and compared to estimates. Controlling is concerned with analyzing measurement data and implementing corrective actions when actual status does not align with planned status.

Leading and directing involves communication and coordination among all project stakeholders, both internal and external to a project. Projects that involve systems engineering are, by nature, high-risk endeavors because, in most cases, projects face many unknown factors that must be handled as a project evolves. Risk management is concerned with anticipating and mitigating potential problems before they become real problems.

Organizational relationships between systems engineering and project management are covered in Parts 5.3 and 5.4. [insert internal links]

Systems Engineering Management

The methods, tools, and techniques of project management can be recursively applied to 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. [Blanchard reference].

Systems engineering contributes to project planning by ensuring that the overall system life cycle is understood, dependencies on other systems and organizations are identified and managed, the logical dependencies during development properly are identified and managed, the systems engineering task is accurately estimated, and resources and key skills are identified and planned. The high-level system architecture and a an assessment of technical risk factors provide the basis for the work breakdown structure and the organizational breakdown structure. One of the key duties of a systems engineer is to develop a range of possible solution strategies with associated costs, schedules, performance envelopes, and risk factors for consideration by key stakeholders. A project or program manager may delegate to the leader of the systems engineering team the tasks of implementing the chosen strategy by working with component specialists, measuring and controlling technical work activities, leading and directing the engineering team, and managing technical risk factors.

Some systems engineers become specialists in systems engineering management.

NOTE: this KA is currently under construction

From 7.3 of v0.25; Systems engineering contributes to project planning by ensuring that the overall system life cycle is understood, dependencies on other systems and organizations are identified and managed, the logical dependencies during development properly are identified and managed, the systems engineering task is accurately estimated, and resources and key skills are identified and planned. The high-level system architecture and a risk assessment should provide the basis for the work breakdown structure and the organizational breakdown structure.

In summary, in project start-ups, SE at the business level should contribute to or lead: • Up-front SE planning and architecting: providing guidance/directive on architecture and life cycle strategy; feasibility evidence and technology pull-through; parametric estimating and management plans; providing and appropriately tailoring the use of organizational standard processes, tools and metrics; Interface standards; modular design and re-use; support, review, and validate bids and proposals. • Resource allocation - people, facilities, knowledge, workspace, infostructure (detailed estimating and tactical management of SE activities and teams is covered in the next chapter, SE management ) • SoS and product line governance: program coherence and cross-project workflow, interoperability, common standards; SoS integration and validation scenarios and acceptance responsibility; product line management

References

Please make sure all references are listed alphabetically and are formatted according to the Chicago Manual of Style (15th ed). See the BKCASE Reference Guidance for additional information.

Citations

List all references cited in the article. Note: SEBoK 0.5 uses Chicago Manual of Style (15th ed). See the BKCASE Reference Guidance for additional information.

Primary References

All primary references should be listed in alphabetical order. Remember to identify primary references by creating an internal link using the ‘’’reference title only’’’ (title). Please do not include version numbers in the links.

Additional References

All additional references should be listed in alphabetical order.

---

Article Discussion

[Go to discussion page]