The systems engineer or SE coordinator of the executing project team typically develops the systems engineering plan. This person translates the project requirements, the chosen SE approach, and the agreements with the client into a workable document that provides guidance for the entire team. The responsibility therefore primarily lies with the contractor, but the client plays an indispensable role in its establishment and verification. In this article, we answer the most frequently asked questions regarding ownership, approval, and maintenance of the systems engineering plan.<\/p>\n
The systems engineering plan is typically prepared by the systems engineer or SE coordinator on the contractor's side. This person has the technical and methodological knowledge to describe the SE approach, determine the verification strategy, and define the roles within the project. On larger projects, an SE manager or lead engineer may take on this task, supported by the project team.<\/p>\n
The author elaborates on the plan based on contractual requirements, applicable SE standards such as the SE Guidance or INCOSE guidelines, and the specific characteristics of the project. It is not a generic document to be filled out once, but a living plan that describes the actual approach. This requires substantive involvement from someone who knows the project and the methodology well.<\/p>\n
In de praktijk zien we dat het opstellen van het SE-plan regelmatig belandt bij iemand die er naast zijn andere taken weinig tijd voor heeft. Het resultaat is dan een document dat meer op papier klopt dan dat het de dagelijkse werkwijze stuurt. Juist daarom loont het om het opstellen serieus te beleggen bij een aangewezen eigenaar met voldoende mandaat en tijd. Wil je weten hoe Datastorms<\/a> teams hierbij ondersteunt? Bekijk dan wat ons platform voor jouw project kan betekenen.<\/p>\n Developing means elaborating on the content of the systems engineering plan: the approach, the methods, the roles, and the agreements. Approving means formally agreeing to that plan, whereby the approving party confirms that the plan meets the stated requirements and the agreed-upon working method. Developing is a substantive task; approving is a formal responsibility.<\/p>\n In most projects, the contractor draws up the plan and the client approves it. Approval is not merely a formality. By approving the plan, the client commits to the described approach and indicates that the chosen SE methodology aligns with the project objectives. A plan approved without a substantive review offers little support in later discussions about scope, verification, or delivery.<\/p>\n In addition to the client, an internal quality manager, an SE review board, or an independent reviewer can also be involved in the approval. In complex infrastructure projects or public tenders, multiple approval layers are common. It is wise to specify in the plan itself who grants which approval and at what point in the project.<\/p>\n The client has a three-part role in the systems engineering plan: they set the frameworks, review the plan for conformity with contractual requirements, and formally approve it. Additionally, the client can impose specific SE requirements, such as the use of certain verification methods, reporting formats, or traceability requirements that the contractor must incorporate.<\/p>\n In some projects, client involvement goes further. They then actively participate in SE reviews, assess verification reports, or take part in system acceptance testing. This is particularly the case for government projects or large infrastructure assignments where the client also possesses SE competencies in-house.<\/p>\n A common mistake is for the client to treat the SE plan as a document to be checked off contractually. This undermines its value. A client who is substantively involved in the creation of the plan increases the likelihood that the plan will actually align with the project objectives and be used as a management tool later, rather than as a desk drawer document.<\/p>\n If Systems Engineering expertise is lacking within the project team, responsibility for the systems engineering plan is often temporarily assigned to an external SE consultant or hired specialist. Another option is to assign responsibility to the project manager or lead engineer, supplemented by guidance from an SE knowledge partner or via a platform that supports the methodology.<\/p>\n Missing SE expertise is a real problem in many organizations. Not every company has a full-time systems engineer on staff, but that doesn't mean SE principles have to fall by the wayside. In practice, there are three common solutions:<\/p>\n The most suitable approach depends on the project scope, available budget, and project duration. For short-term projects, external hiring is often pragmatic. For programs with multiple sub-projects, it is worthwhile to invest in structural tool support and internal knowledge building.<\/p>\n The systems engineering plan must be revised when significant changes occur in the project scope, system requirements, organizational structure, or the chosen SE approach. Additionally, revision is mandatory at pre-agreed milestones, such as after a system review or when transitioning to a new project phase.<\/p>\n An SE plan is not a static document. It describes how the project will execute the SE approach, and if reality changes, the plan must change with it. Typical revision points include:<\/p>\n In practice, revising the SE plan is too often postponed or forgotten. This leads to the plan no longer reflecting reality and losing its guiding value. By managing the plan within a central platform, like the one we facilitate, the current version remains always available, and changes are traceable. This keeps the Systems Engineering plan a living instrument instead of a forgotten appendix.<\/p>\n \n Not every project requires an equally comprehensive SE plan. For smaller or less complex projects, a concise SE approach or a simplified plan that captures the core agreements may suffice. Ultimately, the client's contractual requirements and applicable standards determine the minimum content. It is wise to consciously choose the right level of detail at the start of the project, so that the plan remains workable and is actually used. <\/p>\n <\/div>\n \n A common mistake is blindly copying a generic template without adapting it to the specific project context. Other common pitfalls include: creating the plan without input from the implementation team, describing verification strategies that prove unfeasible in practice, and never updating the plan after approval. The result is a document that looks good on paper but doesn't guide daily operations\u2014precisely the scenario the SE plan is meant to prevent. <\/p>\n <\/div>\n \n The SE plan is only valuable if it is actively used as a management tool. Therefore, ensure that the plan is accessible to all stakeholders, is regularly discussed in project meetings, and is directly linked to the requirements management, verification, and traceability work processes. Tool support greatly aids in this: when the plan and its associated SE activities reside in a central platform, the barrier to consulting and updating it is significantly lower. <\/p>\n <\/div>\n \n In Dutch practice, the terms 'systems engineering plan' and 'systems engineering management plan (SEMP)' are often used interchangeably, but there is a subtle difference. The SEMP is a term primarily found in international standards such as those from INCOSE and places more emphasis on the management aspects of the SE approach, such as planning, resources, and governance. The SE plan, as common in Dutch infrastructure projects \u2013 partly based on the Leidraad SE \u2013 combines both the technical content approach and the management agreements into one document. <\/p>\n <\/div>\n \n The SE plan is complementary to the project plan and the quality plan, but has its own focus: it specifically describes how the SE methodology will be applied to arrive at a system that demonstrably meets the requirements. The project plan focuses on planning, budget, and organization; the quality plan on process quality and assurance measures. In practice, it is advisable to align the three documents and avoid conflicting agreements. References between the documents help to maintain coherence. <\/p>\n <\/div>\n \n Yes, in some projects \u2014 particularly with large government clients or Rijkswaterstaat projects \u2014 the client has its own SE framework or program-level SE plan. The contractor is then obliged to align its own SE plan with this and demonstrate that its approach fits within the client's framework. This requires good coordination in the initial phase of the project and clear agreements on which document is leading in case of any discrepancies. <\/p>\n <\/div>\n \n Begin by gathering the contractual SE requirements and determining which SE standard applies, such as the SE Guideline or a client-specific directive. Then, use a proven template as a starting point and fill it in step-by-step with the project team, so that the plan reflects the actual approach and does not become merely a paper exercise. Consider tool support or guidance from an experienced SE professional for the initial setup \u2014 the investment at the beginning of the project will pay off in clarity and fewer discussions later. <\/p>\n <\/div>\n <\/div>\n Eigenaarschap van het systems engineering plan: wie stelt op, wie keurt goed en wanneer herzie je het?<\/p>","protected":false},"author":3,"featured_media":1873,"comment_status":"closed","ping_status":"closed","sticky":false,"template":"","format":"standard","meta":{"_improvement_type_select":"improve_an_existing","_thumb_yes_seoaic":false,"_frame_yes_seoaic":false,"seoaic_generate_description":"","seoaic_improve_instructions_prompt":"","seoaic_rollback_content_improvement":"","seoaic_idea_thumbnail_generator":"","thumbnail_generated":false,"thumbnail_generate_prompt":"","seoaic_article_description":"","neve_meta_sidebar":"","neve_meta_container":"","neve_meta_enable_content_width":"","neve_meta_content_width":0,"neve_meta_title_alignment":"","neve_meta_author_avatar":"","neve_post_elements_order":"","neve_meta_disable_header":"","neve_meta_disable_footer":"","neve_meta_disable_title":"","neve_meta_reading_time":"","_themeisle_gutenberg_block_has_review":false,"seoaic_article_subtitles":[],"footnotes":""},"categories":[1],"tags":[],"class_list":["post-1791","post","type-post","status-publish","format-standard","has-post-thumbnail","hentry","category-uncategorized"],"_links":{"self":[{"href":"https:\/\/datastorms.eu\/en\/wp-json\/wp\/v2\/posts\/1791","targetHints":{"allow":["GET"]}}],"collection":[{"href":"https:\/\/datastorms.eu\/en\/wp-json\/wp\/v2\/posts"}],"about":[{"href":"https:\/\/datastorms.eu\/en\/wp-json\/wp\/v2\/types\/post"}],"author":[{"embeddable":true,"href":"https:\/\/datastorms.eu\/en\/wp-json\/wp\/v2\/users\/3"}],"replies":[{"embeddable":true,"href":"https:\/\/datastorms.eu\/en\/wp-json\/wp\/v2\/comments?post=1791"}],"version-history":[{"count":2,"href":"https:\/\/datastorms.eu\/en\/wp-json\/wp\/v2\/posts\/1791\/revisions"}],"predecessor-version":[{"id":2194,"href":"https:\/\/datastorms.eu\/en\/wp-json\/wp\/v2\/posts\/1791\/revisions\/2194"}],"wp:featuredmedia":[{"embeddable":true,"href":"https:\/\/datastorms.eu\/en\/wp-json\/wp\/v2\/media\/1873"}],"wp:attachment":[{"href":"https:\/\/datastorms.eu\/en\/wp-json\/wp\/v2\/media?parent=1791"}],"wp:term":[{"taxonomy":"category","embeddable":true,"href":"https:\/\/datastorms.eu\/en\/wp-json\/wp\/v2\/categories?post=1791"},{"taxonomy":"post_tag","embeddable":true,"href":"https:\/\/datastorms.eu\/en\/wp-json\/wp\/v2\/tags?post=1791"}],"curies":[{"name":"wp","href":"https:\/\/api.w.org\/{rel}","templated":true}]}}What is the difference between drafting and approving?<\/h2>\n
What role does the client have in the SE plan?<\/h2>\n
How is responsibility assigned when SE expertise is missing?<\/h2>\n
\n
When should the systems engineering plan be reviewed?<\/h2>\n
\n
Frequently Asked Questions<\/h2>\n
\n Does every project, regardless of size, require a fully developed systems engineering plan? <\/h3>\n
\n What are the most common mistakes in creating a systems engineering plan? <\/h3>\n
\n How do I ensure the systems engineering plan is actually used and doesn't end up gathering dust in a drawer? <\/h3>\n
\n What is the difference between a systems engineering plan and a systems engineering management plan (SEMP)? <\/h3>\n
\n How does the Systems Engineering Plan relate to other project documents like the Project Plan or the Quality Plan? <\/h3>\n
\n Can the client demand their own SE plan in addition to the contractor's? <\/h3>\n
\n How do I practically start creating a systems engineering plan if I have little experience with SE? <\/h3>\n
Related Articles<\/h2>