C Perform Technical Activities

Program implementation occurs with selection of the projects that execute the Program Plan, as discussed in Handbook Section 4.1 Program Formulation Phase. The PM utilizes systems engineering to support the selection process for projects. Clearly defined program requirements help the program and project to adhere to the technical, cost, and schedule commitments during implementation.

Documentation of the requirements at the program and project levels enabled both the program manager and the project manager to hold the XTE project under the baselined dedicated

spacecraft cost. This enabled the next new start of the Mid-EX Program to proceed on schedule despite other areas within the program that had technology challenges. XTE returned $12 million by holding to the original science requirements and resisting “requirements creep.”

– Explorer Program Manager, GSFC

4.2.C.a Systems Engineering

In a single-project program, the program systems engineering (SE) effort ensures that the interfaces between the elements and/or subsystems are well defined and that the systems as defined will operate as planned. The SE effort also verifies compliance to the requirements using a verification matrix throughout the environmental testing of the subsystems and overall system. Single-project programs are typically Category 1, meaning high dollar and high visibility. For example, JWST used a combination of SE, risk management, and reserve management to retire the risk of ten critical technologies prior to reaching PDR. The risk reduction was successfully completed—all ten technologies were independently determined to be at TRL 6 prior to PDR. Systems engineering in single-project programs is essentially the same as it is for any project. Loosely coupled and uncoupled programs have less interdependence between the projects within the program than do single-project or tightly coupled programs. Systems engineering takes place on each project, with little between the projects due to the minimal levels of dependence between the projects themselves. However, there are times where SE trades need to be made between the projects of a loosely coupled or uncoupled program. These could include, for example, which technology to fly on which mission in the program. The program manager, therefore, needs a strong systems engineering effort to support these trades.

Tightly coupled programs have a strong need for program systems engineering because of the interdependence of the projects to accomplish a mission. There are interfaces and performance specifications, as well as derived requirements that are affected by the other projects. SE efforts are critical to the success of the program. If one project falters, it can have devastating effect on the other projects. New technologies are generally part of the tightly coupled program designs. This compounds the risk, because the failure is not isolated to one project and the impacts are also intertwined. In the case of tightly coupled programs such as the Constellation Program, there is a very large Systems Engineering and Integration (SE&I) organization within the program office. During program implementation, the focus of this organization shifts from requirements development and allocation to system design.

Some of the functions of an SE organization for a tightly coupled program include, but are not limited to:

• Ensuring appropriate end-to-end mission analysis is defined and performed to confirm that the integrated design can perform the mission.

• Providing a strong program integration office staffed by experienced integrators to support boards and panels that oversee proposed configuration changes, integrate and evaluate program risks, and similar activities.

• Providing experienced people to work key issues.

A tightly coupled SE organization also contains a strong test and verification component that develops test objectives (ground support and flight hardware and software) from the bottom up and ensures that the program has a comprehensive approach for integrated (total system) verification and validation.

4.2.C.b Decision Making at the Program Level

It is important to make program decisions using all information that is available at the time that the decision needs to be made, but timely decisions often need to be made without complete information. These decisions, regardless of incomplete information, cannot be random and pure chance. They need to be well thought out. Program managers need to evaluate the risk of making a decision, as well as the risk of not making the decision.

The difference between a program manager and a project manager is that a project manager will make a decision pretty quickly to keep the team moving forward where a program manager wants to keep his options open until they absolutely have to make a decision.

– Orbiter Project Manager, JSC

In the decision to fund a parallel path for a high-risk item on one project, the program manager also needs to consider the impact that the decision will have on other projects. A decision to fund a parallel path for a high-risk circuit board, for example, may divert available funds from another activity that may affect a future mission. In other words, the program manager has to consider the risk and impact to the entire program portfolio.

It is also important to revisit decisions as information becomes available to ensure that the decision remains the best answer. There are times when decisions will need to be reversed or the program may decide to move on and live with the consequences of the decision.

In a tightly coupled program or a single-project program, decisions are complex because of the inherent interdependencies between the projects or elements. Schedule becomes a critical factor because completing an element too early or too late can also have impacts to the program. If an element completes early, for example, its technical development team might have to be

disbanded, or the program might have to pay for a costly team waiting for the rest of the program to catch up.

The Decision Analysis Process described in NPR 7123.1 is used to help evaluate technical issues, alternatives, and their uncertainties to support decision making. Only selected decisions are subjected to a formal process. One of the important tasks for the PM early in the program is to establish programmatic guidelines to determine which technical issues are subject to a formal analysis/evaluation process. Decisions about medium- or high-risk activities, program

termination, major changes in program scope, or key personnel changes are good candidates for formal decision analysis.

A formal Decision Analysis Process can assist the PM in reevaluating decisions when more information is available, informing new members of the program staff about the decision history of the program, and defending key decisions at milestone reviews. A history of important

decisions also can help guide future programs and projects. Programs are often not good at documenting the history of decisions and need to improve this process.

Often, decisions only show up in meeting minutes. For small programs, maintaining a file that contains all meeting minutes may suffice. A more extensive approach is to capture the detailed decision information (i.e., decision package) in a central repository. That decision package would include the genesis of the decision, augmenting information, and the assumptions that were considered for the decision. The decision package may also include the alternatives that are considered, the rationale, and the resulting actions from the decision. Examples of results from a decision include change in a requirement, a new requirement, or a new component added to the system of interest. This decision package can be retained in a repository such as a spreadsheet or a database.