3.4.2 Systems Engineering Management Planning

 

OBJECTIVE: The Systems Engineering Management Plan [SEMP] is the repository for project technical plans. The Systems Engineering Management Plan identifies what items are to be developed, delivered, integrated, installed, verified, and supported. It identifies when these tasks will be done, who will do them, and how the products will be accepted and managed. Finally, it defines the technical processes to be used to produce each of the project's products.

DESCRIPTION: he SEMP is an extension of the Project Plan and focuses just on the technical tasks [the tasks covered in this Guidebook]. Preparation of the SEMP is a multi-step process that involves the system owner, systems engineer, and the Development Teams. First, the system's owner or systems engineer develops a framework for the SEMP before any process work starts. This includes the organizational structure, a master schedule for the system implementation, and identification of the technical tasks. For each task the SEMP framework identifies the required outputs, and to the extent possible at this stage, the inputs and processes to be performed. The SEMP framework may define a number of other items including a candidate set of supporting plans, metrics to measure technical performance, and the criteria for technical reviews. The SEMP framework will also tailor the technical processes commensurate with the scope and risk level of the project. Then, the systems engineer and selected Project Development Teams, (experts in the processes to be used) will take the SEMP framework and supply the needed detail for the processes to be used. This will include preparing any supporting plans, for instance, a Software Development Plan or an Interface Control Plan. needed.

CONTEXT OF PROCESS: SYSTEMS ENGINEERING MANAGEMENT PLANNING PROCESS

Project goals and objectives as defined by planning, the regional ITS architecture, and collected stakeholder needs and constraints. Agency capabilities and availabilityis the key input to agency make/buy decisions. Project plan defines all project tasks, including the technical tasks further defined in the SEMP.

Control: Project plan establishes a high level description of the project tasks.

Enablers: Stakeholder involvement is needed to support the project's technical tasks. Procurement options will be analyzed if any technical task is to be contracted out. Risk management is key to developing a SEMP that will anticipate and deal with project problems.

Outputs: Systems Engineering Management Plan defines the project's technical tasks [inputs, processes, and outputs]. Supporting technical plans [optional] are prepared when necessary for a complex project. Request for Proposal [optional] will be needed for any contracted effort.

Process Activities: Assess project management activities and technical tasks: Project management must first determine what project management and technical tasks are going to be required by the project. The needed tasks are driven by the organizational structure and the nature of the products to be delivered. This initial task involves analyzing the project's goals, objectives, constraints, and concept exploration products to identify the needed management and technical plans and actions, such as resource allocation, training, and known constraints. Transitioning Critical Technologies: Risks come in many forms. They usually involve products that have not been built before. These might include novel hardware applications [e.g., new vehicle detector technology], novel software algorithms [e.g., a new approach to adaptive signal control], or challenging performance requirements [e.g., response times, and bandwidth]. Each must be identified as a risk. The technical tasks necessary to address that risk must be included in the SEMP. Define needed systems engineering processes and resources: The project and engineering management will identify the systems engineering processes and resources necessary to support each identified technical task. If significant portions of the systems engineering tasks are contracted to commercial firms, those firms may have to be involved in detailing these processes. Make procurement decisions and specify integration activities: The system's owner will decide, for each technical task, whether the effort can be performed in-house by a consultant or system integrator. For complex engineering efforts, it is quite common to turn to consultants and system integrators. To support such procurements, the system's owner will prepare the necessary contractual documents, including the Request for Proposal. The planned integration steps toward ultimate implementation [“climbing the right side of the Vee”] will be specified. Prepare Systems Engineering Management Plan and supporting plans [as needed]: In order to coordinate the technical activities between all performing organizations, the System Engineer, followed by the development teams, will prepare a Systems Engineering Management Plan. If necessary, separate supporting plans, such as a software development plan and other technical plans identified in the Guidebook.

Where does Systems Engineering Management Planning take place in the project timeline? Where does Project Planning take place in the project timeline?

Is there a policy or standard that talks about Systems Engineering Management Planning?

The FHWA Final Rule does not specifically mention Systems Engineering Plan development practices to be followed.

The IEEE Standard for Application and Management of the Systems Engineering Process [IEEE-1220] focuses on the engineering activities necessary to guide project development. Annex B of IEEE-1220 provides a template and structure for preparing a systems engineering management plan along with an informative discussion of each section and subsection.

Which activities are critical for the system’s owner to do?

This is a process, like project planning, which requires careful oversight by the system’s owner. It can, in part, be delegated to the Systems Engineer or the development teams since they are more familiar with the details of the processes to be employed. Early in the development of the SEMP, the system’s owner and their Systems Engineer should complete a framework that will:

• Identify the core systems engineering planning information that the developer [agency or contractor] must prepare during system design. Examples are: work breakdown structure [schedule tasks and milestones], training, standards, and constraints.
• Identify the control gates in the process where the system owner’s [and other stakeholder’s] review and approval is required.

In addition, the system owner must:

• Determine the resources needed for each process task and who will provide those resources [agency, consultant, or system integrator].
• Select and task the performing organizations [including contractors, as needed].
• Ensure that the systems engineering analysis activities are reviewed, agreed to, and documented in the SEMP.

These tasks will vary depending on the nature of the products to be delivered. They could include: Designing and building custom software or hardware, selecting COTS hardware or software, building and evaluating prototypes, designing complex operator interfaces, and a wide variety of other challenging activities.

How do I fit this step to my project? [Tailoring]

Systems engineering analysis is not one-size fits all. Since systems engineering analysis is intended to address the technical challenges in building a system, it must be tailored to the technical challenges of the specific system.

The biggest variable affecting the scale of the systems engineering analysis is the need to develop custom software applications. If custom software development is needed, requirements definition and design become much more complex and a separate SEMP is usually the best approach.

Projects that only involve the purchase and installation of hardware or hardware with embedded COTS software applications do not require the same depth of requirements analysis and design. Of course, these projects may require serious trade studies on such issues as product selection, site selection, or communications alternatives. The SEMP for such projects may be quite short and can be combined into the Project Plan for efficiency.

Another factor is the degree to which the system owner is comfortable with the technologies involved. If the system owner is unsure or there is a perceived risk, then added attention to the preparation of a SEMP is advised.

The final factor is the degree to which the System Engineer and Development Teams have their own well-developed processes, such as requirements management, configuration management, or software development.

Where the agency does not have any of these processes in place, it is recommended that they identify and select experienced development firms with established processes. In such cases, the SEMP should reference these processes [tailored appropriately] and only deal in detail with the unique processes needed for the project.

What should I track to reduce project risk and to get what is expected? [Technical Measures, Metrics]

On the technical side:

• Technical performance measures [e.g. response times and capacity.] must be defined in the requirements and then shown to be met [simulation and modeling] by the design
• A complete end-to-end trace from user needs and the Concept of Operations to the delivered products

On the project management side:

• The completeness of the documents produced by each task and their correlation with the various technical reviews
• Prompt resolution and incorporation of stakeholder comments to the documents and the technical reviews
• Compliance with the systems engineering analysis processes documented in the SEMP

Checklist: Are all the bases covered?

	Are all needed process steps, along with their process, inputs, and outputs identified?
	Are all known requirements and constraints on the design [specific hardware and COTS software products] incorporated into the process steps?
	Are all necessary technical reviews identified and planned?
	For each process task, are the performing organization and other needed resources, identified and available?
	Is the required content of each deliverable document clear to the performing organization?
	Is the delivery of custom software and supporting documentation clearly specified?
	Is the Configuration Management Plan clear about who needs to approve changes to any baseline?
	Has a selection committee and the selection criteria been established to support each procurement activity?
	Do the design, integration, and verification plans support the deployment goals for the system?
	Are the project risk areas adequately addressed?

Are there any recommendations that can help?

An adequate level of commitment to project management is essential for ensuring the effective delivery and operation of ITS projects. Industry process standards for information technology systems point to the use of the SEMP as that engineering plan for technical control. Although, not specifically called out in federal regulation, the SEMP is considered a critical means of addressing accountability for ensuring both efficient and effective results of any systems engineering.

To the extent possible, the SEMP should plan for all disciplines [development teams] required during the project life cycle and involve the disciplines in each of the technical tasks. At a minimum, this means that some hardware and software design engineers should be involved during the first tasks of the project, including: elicitation of user needs, preparation of a Concept of Operations, and requirements analysis. Likewise, some of the systems engineers, who developed the requirements, should stay involved in the project through the design, production, integration, verification, and deployment tasks. This will integrate the processes and help ensure that the final system meets the original project goals.