A Program is controlled from different axis and these controls are required by different stakeholders. To attend all of them in a efficient way requires understanding of all this.
Program control is a process composed by activities where corporate group ask about the evolution of the program in one area (Finance, legal, quality assurance…). This process has to be established since the program inception.
The aim of a program and project are different. The aim of the program is the realization of expected benefits, through the achievement of desired outcomes. The aim of the project is the delivery of the outcomes and capability. The difference may lead to tensions between project and program control processes. So much people know this and if the program has detractors, they will try to use this tensions to add more pressure.
Re-use communication channels. The communication flow between the program, its projects and the business operations should be based on the governance standards. In this way, when control activities are required, if documentation and communication channels are well established, the addition of these stakeholders is easier.
Manage a program does not mean micro-management of its projects. Projects should be empowered but need tolerances and limits, in order to ensure that they do not exceed their delegated authority. Allowing the project managers to manage their projects within the tolerances set by the program is a essential part of good program management. It will also give a clear view to the “controllers” about the situation of the program.
Ask Delivery Assurance. Big corporations have DA groups or QA teams that execute audits on programs and projects. Even if you have go through these processes, it is good to ask during the definition of the program, when the QA audits will be performed, what type of information they are going to require, and if there are extra requirements.
Keep your map of dependencies. You will have 1) internal dependencies to the project, 2) intra-dependencies on other programs and 3) external dependencies. When something fails in a program and you are reporting to a control audit you will be asked about “why” this is affecting you and what is the impact. To have a dependency map, looking into the projects as back boxes with inputs/outputs, will provide a crucial control tool for the program manager. Project assumptions is a source of information for program dependencies: use them, and ensure they are coordinated and understand the program dependencies that could affect to them.
WordPress
Google + 
Facebook