With a LOE project or program, the PM does not have that ability. Instead, if the design team has under estimated the complexity or risk in meeting a requirement, they have the ability to refactor the requirement into two or more requirements. They can then complete the first of these during the current segment and the others during later segments. The fact that I'm using the term segment implies that I think that an LOE effort can only be successfully used with short cycle efforts; each segment being a cycle. So, in short cycle, agile, LOE efforts, the System Requirements are the variable, while the budget and schedule are held as constants.
For example, since LOE projects and programs produces a uniform amount of output for each equal segment of these development or transformation efforts, there is little need for metrics like "Earned Value". This is particularly true in short cycle development and transformation efforts where the customer can see and use the work products. If properly performed at the end of each cycle, be it monthly or every 3 months, either the IOC version or an upgrade is rolled out. It can be rolled out into the operational environment, or in some cases into a preproduction environment (an environment where the customer can use the new system in parallel with the old system). Since the customer can use the IOC or upgraded system, what is the purpose of metrics like the "Earned Value" metrics (since the goal of the EV metrics is to show progress)?
Changes in Roles and Responsibilities of the Team
- There is a requirement for capturing new requirements in every cycle of the effort. This is within the role of the Systems Engineer.
- There is a requirement for the customer to prioritize the complete set of requirements at the start of each cycle.