- Briefing Room
U.S. Department of Transportation
Federal Highway Administration
1200 New Jersey Avenue, SE
Washington, DC 20590
Purpose of this Document
The SEMP [Systems Engineering Management Plan], may be needed to supplement the details of the Project Plan. When used, the SEMP focuses on the technical plan of the project and the systems engineering processes to be used for the project. Its purpose is to detail out those engineering tasks; especially to provide detailed information on the processes to be used. Preparation of a SEMP is most important if the project involves development of custom software. The engineering tasks of producing custom software [from requirements, through design implementation, integration, and verification] are very complex, and are new to many transportation engineers.
Given the level of process detail needed in the SEMP, it often written in two steps. In the first step, the framework for the document is prepared, usually by the project management staff. Enough detail is included to identify all the needed tasks [including analysis tasks] and any important constraints on the performance of a task [such as use of a specific systems engineering and design methodology]. In the second step, the various sections of the SEMP framework are completed, this time by the team that will perform each task. For instance, the requirements team provides details on the analysis and the tools used to manage requirements. The design team provides details on use of the software design methodology. The software coder provides details on configuration management of the software code. The verification team provides details on their verification methods.
These SEMP template were adapted from guidelines prepared by the Caltrans Office of Local Assistance. See the web page at: http://www.dot.ca.gov/hq/LocalPrograms/lam/prog_g/g12othr.pdf .
Tailoring this Document to Your Project
The simplest ITS projects may not need a SEMP; the Project Plan may be sufficient. Among the project complexities that make preparation of a SEMP desirable are:
Checklist: Critical Information
|Are all the technical challenges of the project addressed by the systems engineering processes described in the SEMP?
|Does the SEMP describe the processes needed for requirements analysis?
|Does the SEMP describe the design processes and the design analysis steps required for an optimum design?
|Does the SEMP clearly identify any necessary supporting technical plans, such as a Verification Plan or an Integration Plan? Does it define when and how they will be written?
|Does the SEMP spell out stakeholder involvement when it is necessary?
|Does the SEMP identify all the required technical staff and development teams? Does it identify the technical roles to be performed by the system’s owner, project staff, stakeholders, and the development teams?
|Does the SEMP cover the interfaces between the various development teams?
SYSTEMS ENGINEERING MANAGEMENT PLAN TEMPLATE
The title page should follow the Transportation Agency procedures or style guide. At a minimum, it should contain the following information:
1.0 Purpose of Document
This section is a brief statement of the purpose of this document and the plan for the systems engineering activities with special emphasis on the engineering challenges of the system to be built.
2.0 Scope of Project
This section gives a brief description of the planned project and the purpose of the system to be built. Special emphasis is placed on the project’s complexities and challenges that must be addressed by the systems engineering efforts.
This section also describes the environment in which the project will operate. It identifies the organization structures that encompass all stakeholders. It gives a brief description of the role to be played by each stakeholder. This includes ad hoc and existing management work groups and multi-disciplinary technical teams that should be formed or used to support the project. Such teams are critical to reaching successful system deployment.
This section defines the general process for developing the SEMP, including the draft framework version prepared by the transportation agency or their Systems Engineer and the complete version prepared in conjunction with the Systems Engineer and Development Teams.
3.0 Technical Planning and Control
This section lays out the plan for the systems engineering activities. It must be written in close synchronization with the project’s Project Plan. Unnecessary duplication between the Project Plan and the SEMP should be avoided. However, it is often necessary to put further expansion of the systems engineering effort into the SEMP even if they are already described at a higher level in the Project Plan. Even within the SEMP, an effort may need to be described at a higher level in the draft SEMP framework. Then it may need to be expanded further in the final version of the SEMP. An example would be the Configuration Management Plan, to be described below.
The purpose of the section is to describe the activities and plans that will act as controls on the project’s systems engineering activities. For instance, this section identifies the products of each systems engineering activity, such as, documentation, meetings, and reviews. This list of required products will control the activities of the team performing the activity and will control the satisfactory completion of the activity. Some of these plans may be completely defined in the SEMP [in the framework or the complete version]. For other plans, the SEMP may only define the requirements for a particular plan. The plan itself is to be prepared as one of the subsequent systems engineering activities, such as may be the case with a Verification Plan or a Deployment Plan. Almost any of the plans described below may fall into either category. It all depends on the complexity of the particular plan and the amount of up-front systems engineering that can be done at the time the SEMP is prepared.
The first set of required activities/plans relates primarily to the successful management of the project. These activities are likely to have already been included in the Project Plan, but may need to be expanded here in the SEMP. Generally, they are incorporated into the SEMP; but, on occasion, may be developed as separate documents.
The second set of plans is designed to address specific areas of the systems engineering activities. They may be included entirely in the SEMP or the SEMP may give guidance for their preparation as separate documents. The plans included in the first set listed above are generally universally applicable to any project. On the other hand, some of the plans included in this second set are only rarely required. The unique characteristics of a project will dictate their need.
This second list is extensive and by no means exhaustive. These plans should be prepared when they are clearly needed. In general, the need for these plans become more important as the number of stakeholders involved in the project increases.
4.0 Systems Engineering Process
This section describes the intended execution of the systems engineering processes used to develop the system. These processes are generically described in the Guidebook and identified in the VEE life cycle technical development model. The SEMP describes the processes specifically needed for a project. It defines them in sufficient detail to guide the work of the systems engineering and development teams.
The FHWA’s Final Rule [23 CFR Part 940 part 11] places requirements on the minimum description of the systems engineering analysis for projects funded with highway trust funds. For all projects, the following factors should be discussed in the SEMP:
This section will contain a description of the systems engineering procedures tailored to the specific project. There are four areas of analysis that need to be described:
5.0 Transitioning Critical Technologies
This section will describe the methods and processes to be used to identify, evaluate, select, and incorporate critical technologies into the system design. Since this may represent an area of considerable impact to the project, this is one of the major efforts of risk management.
The need for a critical technology may be based on a performance objective. It may also be based on other factors; the desire to reduce acquisition or maintenance costs; the need to introduce standard compliance; or the need to meet an operational objective. In some cases, the need may move away from a technology that is obsolete and no longer supported by industry.
Identification of candidate technologies hinges on a broad knowledge of the technologies and knowledge of each technology’s status and maturity. In other words, build on a thorough understanding of the pros and cons of each available technology. Obtaining the resource[s] capable of performing this step is one of the major risks encountered by project management.
Sufficient analysis of the risks and benefits of a particular technology may become a major effort involving acquiring the technologies, modifying the technology to meet system requirements, and developing methods to test and evaluate the various technologies that need to be considered. Each of these steps can introduce considerable risk.
Finally, incorporation of a technology into an operational system may involve considerable work, especially establishing the support and maintenance environment for the technology.
All of these aspects of technology introduction, especially introduction of novel technology, need to be carefully and fully addressed in the SEMP.
6.0 Integration of the System
This section describes the methods to be used to integrate the developed components into a functional system that meets the system requirements and is operationally supportable. The systems engineering process steps to be detailed here include: integration, verification, deployment, and the training necessary to support operations & maintenance. Plans for validation of the system should also be covered. For each step, the resources [tools and personnel] are identified and products and criteria for each step defined.
7.0 Integration of the Systems Engineering Effort
This section addresses the integration of the multi-disciplinary organizations or teams that will be performing the systems engineering activities. Obviously, the larger the number of such organizational teams, the more important the integration of their efforts is. Each team will have both primary and support tasks from the WBS. Each team will have to be aware of the activities of other teams, especially those activities that immediately precede or follow their own primary tasks. Representatives of most teams will have to be involved in critical technical reviews, and in the review of baseline documentation. Likewise, up-front teams [e.g. requirements and design] must be available to support the ending activities, such as, integration, verification, deployment, and training.
8.0 Applicable Documents
This section lists the applicable documents which are inputs to the project [i.e., needed but not produced by the project]. Such documents may include: the regional ITS architecture description, planning documents describing the project, agency procedures to be followed, standards & specifications, and other descriptions of interfacing external systems. Other applicable documents may be required by a specific project.