A SEMP is a project-specific plan that sequences the important activities of a program, with particular emphasis on provisions for oversight and mid-course correction. In this context, “sequencing” means that the SEMP might lay constraints on certain activities such that they are predicated on successful progress on other activities. Such constraint may be of any type (e.g., start-to-start, finish-to-finish) based on the technical and programmatic relationships between the CI’s and tasks in question. Where such constraints are identified, the SEMP must explain (or point to) the rationale for the constraint.
For complicated projects with sophisticated CI’s, the level of detail in a SEMP might do no more than sequence the occurrence of the developmental milestones for major CI’s. For other projects, it might dive into the details of lower-tier CI’s in order to relieve their management of the need for stand-alone SEMP’s. It is possible that, for a mix of complicated and simple CI’s, a top-level SEMP might do some of both extremes.
Because the SEMP deals with the sequencing of information about the entire project, it is a good place to address the DAC and VAC, if the concepts are to be used on the subject project. The VAC may, however, be deferred to the MVP, if one is used.
Although it is tempting1 to include schedule information in a SEMP, it would be better to leave that information out of the document. Being subject to the vagaries of funding, maturation of technical comprehension, and the vicissitudes of developmental fortune, inclusion of schedule will either cause the SEMP to undergo constant revision or to quickly become out of date. In either case, the coordination of the project (which is the whole purpose of the SEMP) will be adversely impacted.
Contrast with System Management Plan.
Footnotes- And, in some command media, required.[↩]