Let's remember first that a Program is "a group of related projects managed in a coordinated way to obtain benefits and control not available from managing them individually". Interpreting the definition, there are actions that could be taken in order to improve the whole result, even though some of these actions could be bad for a project in particular. In this article, I'm going to explore the basic actions for a program.
I have used certain common graphs to oversee programs for years that I'm going to change in this article, in order to present a new graph that bears in mind concepts of "earned schedule".
In the following graph, every bubble is a project. As it was explained at definition, I have replaced the x-axis by SPI, calculated as ES/AT instead of EV/PV. Otherwise, using the classical definition of SPI, every project is going to finish over the y-axis. Using SPI=ES/AT, the final position of a project will be determined by the time performance.
In this graph, the size of a bubble is determined by ETC. According to this, every project is going to end as a point.
In the following quadrant, we see the result of a bad estimation or a remarkable execution. In any case, it's better to analyze details because there is an opportunity of improvement. If the EAC confirms the tendency, my recommendation is to cut budget of the yellow project as a formal change control and increase the budget of the red project in the opposite quadrant. With the increment of budget, the red project should "buy time" that means to use the new economic resources to improve the time performance.
In the following quadrant, we see a more common situation. The blue project has a bad cost performance with a good time performance. If the EAC confirms the tendency, my recommendation is to "sell services" to the green project in the opposite quadrant. It means that blue project is going to be delayed because of a new charge of work, but this is not a problem. In return, the green project is going to release the economic resources that the blue project needs. Both changes need to be formal; otherwise we are going to patronize a bad practice: scope creep.
The last recommended actions are only ideas for an hypothetical ideal situation. Not always the proposed changes can be done. Naturally, the program manager needs to apply his own criteria after consider the real conditions.