C Program Technical Activities

The degree of technical involvement of the program with the projects depends on the type of program involved. For single-project and tightly coupled programs, technical planning and execution is the role of the program office. A program-level Systems Engineering Management Plan (SEMP) is developed similar to the ones developed by the projects in uncoupled or loosely coupled programs. This document defines all systems engineering activities. The program office may also need to initiate development of technologies that cut across multiple projects within the program. These technical activities can be initiated through a technology development plan. This plan describes how the program will assess its technology development requirements, including how the program will evaluate the feasibility, availability, readiness, cost, risk, and benefit of new technologies. For loosely coupled and uncoupled programs, much of the technical planning and execution is conducted at the project level; however, the program office generally provides a chief engineer or technical manager to oversee project technical activities.

4.1.C.a Technology Assessment

Technology assessment identifies the major critical technological advancements required for a program/project. It is extremely important to define a technology assessment process at the beginning of the program/project and to perform this assessment at the earliest possible stage (concept development) and throughout the program.

NASA Systems Engineering Handbook SP-2007-6105 Rev 1 describes how to perform

technology assessments. The process begins by determining technological maturity via NASA’s Technology Readiness Level (TRL) scale. This process also guides determining the requirements needed to advance the level of maturity. Conducting technology assessments at various stages throughout a program/project is required to provide Key Decision Point (KDP) products necessary for transition between phases.

In some cases, the degree of technology insertion is schedule driven; a very aggressive program schedule may limit the amount of new technology considered, or only mature technologies may be candidates. In other cases, inability to achieve critical requirements (e.g., mass reduction) may drive a search for new technology to meet requirements.

At the beginning of a program, the PM should appoint a responsible individual to determine and evaluate technology needs and options. The PM should be aware of relevant developments and their level of maturity. The PM can be advocate and sponsor, when appropriate, and develop a transition plan. Also be aware of technologies developed through the Small Business Innovation Research (SBIR) program. Significant insight into technologies where investments have

occurred can save time and resources if the program requires an alternative.

4.1.C.b Developing Descope Options

Descope simply means that the original program has been partly reduced in capability. Program descopes can include anything from removing an entire project to removing parts of projects (e.g., an instrument, reducing the capability of a system, shortening the operational life of the mission,). Descopes are most often caused by the program’s inability to continue funding an item. They can also be caused by unavailability of a new technology that was expected but cannot be delivered on time.

Establishing baseline requirements as well as a floor or minimum acceptable program or project (a level below which the program or project should not go forward) is necessary. This method can be applied to any new program or project and the agreed-to minimum acceptable mission can be used to bound descope options. Descopes must not cut a project below the minimum success criteria needed to carry out the missions in the program. If a descope is invoked, it is necessary to take a systems view to ensure that all potential interactions are identified.

It is important to identify potential descopes early and to get sponsor buy in. It is also important to identify the risk associated with taking potential descopes. Many potential descopes are possible and beneficial when taken early in the program life cycle but may be much less useful or even increase overall program or project risk when taken late in the life cycle. When

identifying a descope, the analysis should include a date by which each descope needs to be taken and the associated risks of taking the descope.

Although descoping is sometimes necessary, it should be used as a last resort. Having a good plan and monitoring status, using tools such as the Integrated Master Schedule and Earned Value Management, are key to early problem identification. Early identification can possibly preclude the need to descope.

One program was forced to remove content that did not have a set of minimum or threshold requirements from the original scope of the program. To realign the program’s scope, the PM assembled key stakeholders, including all levels of Technical Authority, and “put everything on the table.” Every potential descope item was ranked in terms of risk versus benefit. Items that were essential or that the team did not want to eliminate were determined relatively quickly. For nonnegotiable items, the team didn’t waste time debating; however, as part of the process, everything was questioned. After this process was concluded, the PM communicated the decisions and rationale to the entire team.

This example describes a thorough process for developing descope candidates. However, had a descope analysis been developed early in the program (proactively), the team would have had a descope list ready to be implemented if and when necessary. The last-minute reaction would have been avoided.

On another program, the team maintained a descope list with actions and the rationale behind the action as well as any resulting program risks and updated the list periodically. Exercising

descopes early on was key to the program staying within its cost and schedule baseline.

Frequently, a descope occurs as a reaction to an unplanned budget cut or a continuing resolution; the budget challenge is met with resulting reductions in program scope. This type of scope change cannot be preplanned; it occurs as a result of various trades to achieve the optimum program content or scope that the new budget (and/or schedule) will allow.