California Division | Federal Highway Administration

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 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 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.

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.

• Work Breakdown Structure [WBS] [also included in the Project Plan] a list of all tasks to be performed on a project, usually broken down to the level of individually budgeted items
• Task Inputs is a list of all inputs required for each task in the WBS, such as source requirements documents, interface descriptions, and standards.
• 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 completed
• Reviews and Meetings is a list of all meetings and reviews of each task in the WBS
• 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
• Systems Engineering Schedule a schedule of the systems engineering activities that shows the sequencing and duration of these activities. The schedule should show tasks [at least to the level of the WBS], deliverable products, important meetings & reviews, and other details needed to control and direct the project. An important management tool is the schedule. It is used to measure the progress of the various teams working on the project and to highlight work areas that need management intervention

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.

• Software Development Plan describes the organization structure, facilities, tools, and processes to be used to produce the project’s software. Describes the plan to produce custom software and procure commercial software products
• Hardware Development Plan describes the organization structure, facilities, tools, and processes to be used to produce the project’s hardware. It describes the plan to produce custom hardware [if any] and to procure commercial hardware products
• Technology Plan if needed, describes the technical and management process to apply new or untried technology to an ITS use. Generally, it addresses performance criteria, assessment of multiple technology solutions, and fall-back options to existing technology
• Interface Control Plan identifies the physical, functional, and content characteristics of external interfaces to a system and identifies the responsibilities of the organizations on both sides of the interface
• Technical Review Plan identifies the purpose, timing, place, presenters & attendees, subject, entrance criteria, [a draft specification completed] and the exit criteria [resolution of all action items] for each technical review to be held for the project
• System Integration Plan defines the sequence of activities that will integrate software components into sub-systems and sub-system into entire systems. This plan is especially important if there are many sub-systems produced by a different development team
• Verification Plan almost always required, this plan is written along with the requirements specifications. However, the parts on test conduct can be written earlier
• Verification Procedures are developed by the Development Team and this defines the step by step procedure to conduct verification and must be traceable to the verification plan
• Installation Plan or Deployment Plan describes the sequence in which the parts of the system are installed [deployed]. This plan is especially important if there are multiple different installations at multiple sites. A critical part of the deployment strategy is to create and maintain a viable operational capability at each site as the deployment progresses
• Operations & Maintenance Plan defines the actions to be taken to ensure that the system remains operational for its expected lifetime. It defines the maintenance organization and the role of each participant. This plan must cover both hardware and software maintenance
• Training Plan describes the training to be provided for both maintenance and operation
• Configuration Management Plan describes the development team’s approach and methods to manage the configuration of the system’s products and processes. It will also describe the change control procedures and management of the system’s baselines as they evolve
• Data Management Plan describes how and which data will be controlled, the methods of documentation, and where the responsibilities for these processes reside
• Risk Management Plan addresses the processes for identifying, assessing, mitigating, and monitoring the risks expected or encountered during a project’s life cycle. It identifies the roles & responsibilities of all participating organizations for risk management
• Other plans that might be included are for example, a Safety Plan, a Security Plan, a Resource Management Plan, and/or a Validation Plan

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.