The title page should follow the Transportation Agency procedures or style guide. At a minimum, it should contain the following information:

• SYSTEMS ENGINEERING MANAGEMENT PLAN FOR THE [insert name of project] AND [insert name of transportation agency]
• Contract number
• Date the document was formally approved
• The organization responsible for preparing the document
• Internal document control number, if available
• Revision version and date issued

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.

This section gives a brief description of the planned project and the objectives 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.

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.

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. 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 first set of activities/plans listed below relate primarily to the successful management of the project. These should be created for almost any project. They may be a part of the Project Plan, but if not should be part of the SEMP.

• Work Breakdown Structure [WBS] [also included in the Project Plan] is a list of all tasks to be performed on a project, usually broken down to the level of individually budgeted items.
• Task Deliverables is a list of the required products of each task in the WBS, including documents, software, and hardware.
• Task Decision Gates is a list of critical activities that must be satisfactorily completed before a task is considered complete.
• Reviews and Meetings is a list of all meetings and reviews of each task
• Systems Engineering Schedule is a schedule of the systems engineering activities that shows the sequencing and duration of these activities.

·        Risk Management Plan addresses the processes for identifying, assessing, mitigating, and monitoring the risks expected or encountered.

These next set of activities should be considered for inclusion in the SEMP if they have particular importance to the project, but will likely not be included in most SEMPs.

• Task Resources is identification of resources needed for each task in the WBS, including for example, personnel, facilities, and support equipment.
• Task Procurement Plan is a list of the procurement activities associated with each task of the WBS, including hardware and software procurement and, most importantly, any contracted services, such as systems engineering services or development services
• Critical Technical Objectives is a summary of the plans for achieving any critical technical objectives that may require special systems engineering activities. It may be that a new software algorithm needs to be developed and its performance verified before it can be used. Or a prototyping effort is needed to develop a user-friendly operator interface. Or a number of real-time operating systems need to be evaluated before a procurement selection is made. This type of effort is not needed for all projects

This section describes the intended execution of the systems engineering steps used to develop the system. These steps are generically described in Chapter 3. 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.

This section will contain a description of the systems engineering procedures tailored to the specific project. There are four areas of analysis that are usually described, depending on the nature of the project:

• System Requirements Analysis describes the methods to be used to prepare the Concept of Operations and the top-level system requirements documents. The analysis techniques that may be used include: peer reviews, working groups, scenario studies, simulation, and prototyping. The amount of analysis required increases with the risk of the specific requirement. The process for approving the resulting documents will be described, including who is involved, whether technical reviews are necessary, and how issues and comments are resolved so the baseline can be defined
• Sub-system [Functional] Analysis describes the methods to be used to identify sub-systems and to allocate the system [top-level] requirements to the sub-systems. It is often necessary, at this step, to expand the top-level requirements into a complete description of the functions of the system, for instance, details of an operator interface. It also may be necessary, at this time, to define internal interfaces [sub-system to sub-system] to the same level of detail as the external interfaces [interfaces to other systems]. The SEMP should describe the methods for analysis and the tools required. Budget and schedule constraints, as well as completion criteria, should be included
• Design Synthesis describes the methods to be used by the development teams to translate the functional requirements into a hardware and software design. A number of tools and methodologies exist for this. The specific ones to be used by the development team should be identified, along with the necessary resources. Describe the products to be produced as this process unfolds and the design review steps to be taken
• System Analysis describes the methods to be used for any required technical trade-off studies, cost/benefit decisions, and risk mitigation alternative analysis. The methodologies used should provide a rigorous basis for selecting an alternative, a quantifiable basis for comparing the technical, cost, and schedule impacts of each alternative, and comprehensive description of the risks involved with each alternative.

This section will describe the methods and processes to be used to identify, evaluate, select, and incorporate critical technologies into the system design. If the project includes critical technologies, then this section will represent an area of importance to the project, since it is one of the major efforts of risk management. For many projects, using existing, well-defined technologies, this section will not be relevant to the SEMP.

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.

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 steps to be detailed here include: integration, verification, transition, 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.

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.

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.