---

Contents

• Prerequisites
• PM and SE roles and responsibilities
  • PM responsibilities
  • Chief SE responsibilities
  • Controls manager responsibilities
  • Dividing these roles and responsibilities
• How to create a system hierarchy
  • Schedule, Cost Budget, and TPMs
  • Allocations to the system hierarchy
  • Reviews

Prerequisites

To understand the content on this page, you should have read the SE Overview Wiki, as well as the Video Series Summary Wiki. This seminar was directed at audiences that had viewed the video series, therefore, this Wiki is directed at those who have read both of the aforementioned Wikis.

If you need confidence in the Systems Engineering process, I recommend that you watch 1:19:05 – 1:22:24 and 1:29:12 – 1:37:38. Honestly, I think it might be best to watch this before trying to learn SE so that you're a believer and not just a blind follower.

PM and SE roles and responsibilities

Generally, the top level of management manages 3 things: the stakeholders (anyone who can affect the system or can be affected by the system), technical work, and controls (schedule and cost budget).

The stakeholders are managed by the Project Manager, the technical work is managed by the Chief Systems Engineer, and the controls are managed by the Controls Manager.

PM responsibilities

The PM is careful to manage all of the stakeholders. They are THE point of contact for all stakeholders, as well as for the general public. Importantly, they set and manage expectations for all stakeholders. The PM has to get all of the stakeholders to at least agree with the project goals, even if some can't get their way.

The PM is further responsible for removing obstacles from the team so that they can deliver.

If the PM is thus far successful, they are also responsible for new business acquisition. In our case, this can be getting members hired.

Chief SE responsibilities

The Chief SE is responsible for managing the System such that once it is completed, it can be used to accomplish its mission. This means the Chief SE is responsible for:

• All design. All Design.
  • He defines "design" to be SE design, whereas "Design" to be traditional engineering design.
• All technical communication.
  • Whenever any technical aspect of the system needs to be explained to a stakeholder, the PM goes to the Chief SE.
• Ensuring validity, consistency, completeness, and coherency.
• The measuring, monitoring, and evolution of the TPMs.
• Ensuring that all ilities are addressed throughout the Project Life Cycle.
• All system integration
• All verification and testing

Controls manager responsibilities

The Controls manager is responsible for:

• The schedule
  • Plans the entire timeline, from cradle to grave
  • Measures schedule adherence
    • Sometimes, people swear that everything is going according to schedule until the day of delivery when you find out they're nowhere close. He doesn't offer a suggestion to prevent this, so I will suggest agreeing with them to receive proof of schedule adherence throughout (i.e. by X date, you can show me this part is done).
  • Maintains and updates the schedule
• The cost budget
  • Plans what the entire project is going to cost and compares that with how much money they can get
  • Measures cost budget adherence
  • Maintains and updates the cost budget

Therefore, the Controls manager works closely with the PM and CSE

Dividing these roles and responsibilities

If the project has 7 or fewer people, one person takes on PM, CSE, and Controls Management. This person always does some technical work, too.

If the project has 8 or more people, the roles can be broken down in a few ways:

• One person is the PM & CSE, with another person as the Controls Manager.
• One person is PM & Controls Manager, with another person as the CSE.

If the project is much larger than 8, one person will do PM, one CSE, and a third will manage Controls. Each of these people typically has a large staff.

From his description, I think our team of about 30 best fits the medium-sized organization.

How to create a system hierarchy

There is no single "correct" system hierarchy. It is the result of a creative "d"esign (SE design) process.

Schedule, Cost Budget, and TPMs

We do not want any schedule, cost budget, or TPM surprises. If they are large enough surprises, or late enough, we may fail to make it to the competition.

These surprises come to be because the problem space always evolves. Therefore, the schedule, cost, and technical performance evolve too. To avoid big surprises late in the process, we plan for this evolution.

He recommends planning how often to review the schedule, cost budget, and TPMs. Also, he suggests we have a plan for what to do when variances arise. For example, if a part comes in 10% over the expected cost, do you still buy it? 30%? 100%? As long as you have a plan, when variances arise, you will know what to do.

Plans are just making decisions and writing them down. I would add that the justification for the decision should be written as well. This way, you can remind yourself why the choice was made and decide whether that logic still makes sense.

Allocations to the system hierarchy

All allocations should be done with margins.

Allocations to cost budget and TPMs can be managed with give-and-take (one item may be more expensive while others a bit cheaper, so you can reallocate resources). Not time. Time spent is gone forever. That's why it's so important to focus on your critical path (and schedule this with margins).

Some allocations cannot be a simple add-up, such as reliability.

Reviews

At every control gate, you should have (at a minimum):

• the new hierarchy decomposition
• new level of functional flow
• new level of interfaces (N^2 chart)
• new level of conops
• new level of data/communication flow
• new level of timeline analysis
• new level of ility considerations
• new level of verification and testing plan

At SRR, we are trying to successfully constrain the problem space. The requirements are gleaned from customer documents (the guidebook). If there are any uncertainties, ask.

At PDR, we have a formal baseline (stated as requirements) that we are ready to hand off to the traditional engineers.

At CDR, we review the Design. That is, CAD models, drawings, electrical schematics, software pseudocode, etc. This tends to be about 90% of the final Design. There will be some small changes later. After this review, the team is ready to begin spending money on construction.

There can be multiple PDRs and CDRs (by subsystem and then an overall system review), but only one SRR.