First let's define what I mean by a program. If you refer to my page on project complexity, you find that the most complex type of project is a program. A program is a large multi-year, multi-deliverable proejct that normally costs millions of dollars and will have hundreds of people working on it at some point in time. The recommendation for managing a program was to break it into a family of inter-related sub-projects that have their own Project Leader. The Program Manager's role is to manage the interfaces and relationships between the sub-projects. When a problem arises on one sub-project, the Program Manager must work with the Project Leader to drive the problem to a satisfactory solution, or sometimes to shift the problem resolution to a different sub-project that is better able to address the issue.
Therefore the Program Manager does not personally manage the day-to-day activities within all of the sub-projects. However, the Program Manager is the primary stakeholder for each of the sub-projects and is involved in the oversight and risk resolution activities within each sub-project. Ideally, the Program Manager is an experienced Project Leader and understands how to plan, execute and control a project. But, the Program Manager must be able to step back and not begin to micro-manage all of the sub-projects. There are a number of tools and techniques that will assist the Program Manager in their role. These include the application of the systems engineering discipline, the use of Interface Control Documentation to manage the scope interfaces between sub-projects, the use of Milestone Alignment charts for schedule integration between projects, the use of a Staffing Management Plan for personnel resource alignment, and Program Management Reviews for program control. As mentioned on the Project Team Leadership page, two vitally important characterisitcs of successful program management are communication skills and risk management. Other tools and techniques that are discussed on other pages and that apply to program management include:
- Requirements Document
- Network Diagram
- Work Breakdown Structure
- Budget Baseline
- Technical Reviews
- Earned Value Analysis
Systems Engineering
The Systems Engineering discipline as applied to programs is as much a philosophy as it is an engineering discipline. In this case Systems Engineering starts with the final business impact of the program and considers all of the needed activities necessary to successfully implement the program. For instance, a new product development program targeting products for a new market may need to develop a product, build a new factory in a differnet country, create a new logistics process, implement a new ERP system, and develop a new sales and service operation. All of these sub-projects must comply with a myriad of standards and regulaotry requireemetns. Each of these sub-projects are very different in terms of the scope of work and the needed technical skills. Yet each of these sub-projects must complete their sub-project goals to an overall program schedule and integrate with the other sub-projects so that the new product can be successfully launched in the new market. The Systems Engineering discipline translates the overall program goals into detailed sub-project requirements.
In addition, the Systems Engineering activities will establish quality attributes and success criteria for the sub-proejct deliverables that will ensure the overall program is able to meet the program quality and success criteria. The definition of requirements and trackig of successful attainment of the requirements is often maintained in a Systems Engineering Management Plan (SEMP). The SEMP will contain the Traceability Matrix (discussed on the Scope Planning page) for each of the sub-projects. Often there is a significant amount engineering analysis needed to establish the performance and lifecycle requirements for aspects of the system that are effected by multiple sub-projects. This analysis can take weeks or months to complete, yet it is a crucial portion of the overall program lifecycle and must be done prior to the initiation of the sub-projects.
Interface Control Documentation
Interface Control Documents (ICDs) are the mechanism used to communicate technical requirements and interfaces between sub-project teams. These must be managed by the Program Manager because there will inevitably develop confusion and conflicts between the sub-project teams concerning technical interfaces. Some of the more common items documented on ICDs are mechanical interfaces, electrical interfaces, acceptable tolerances, datastream definition and protocols, thermal interfaces, electromagnetic interfaces, loads and moments, hazardous materials and hazardous waste, and material compatibility. This is not an exhaustive list, rather it an illustrative list. Some of these may not apply on your program, but there may be other technical requirements that do apply and are not listed.
The development of ICDs is often as much political as it is technical. One of the sub-projects is tasked with creating an intial draft ICD that is then reviewed and commented upon by all of the affected sub-projects. This is where it is necessary for the Program Leader to engage. The initiating sub-project will often bias the ICD in the direction that minimizes risk within their sub-project - for instance they may impose excessively tight tolerances on parts and systems coming from other sub-projects. The Program Manager must consider the risk to each sub-project and the overall risk to the program of the different options for interface definition. Given the strengths and weaknesses of the project plan and the project team within each of the sub-projects, the Program Manager makes the best program decision and then communicates that decision through the ICDs. In my experience it is best to treat the ICD as a revision controlled document and, when working with multiple companies, placing the ICD on the contract as a controlled document.
Milestone Alignment Schedule
The type of schedule can be created in a Gantt chart format where each integration milestone is a line on the Program Gantt or it can created as a pipeline chart where each of the sub-projects is a pipe and the integration milestone linking the pipelines are shown. I have used both approaches and both are acceptable. The example shown is a pipeline chart.
Staffing Management Plan
The staffing management plan is used by the Program Manager to optimize the resource pools that are shared across several sub-projects. The staffing management plan typically shows the resource needs in a set of histograms where each bar represents the needs during a particular time period such a month or quarter. The staffing management plan provides insight to the Program Manager concerning possible people shortages or skill shortages on the program. The Program Manager then can work with Human Resources to fill the gaps with permanent or temporary staffing. Also, the Program Manager can work with the sub-project leaders to change schedule boundaries on the sub-projects that will alleviate staffing concerns without delaying the end date of the program.
Developing the staffing management plan can be difficult. Often the sub-project leaders are unable to provide resource estimates without first conducting detailed planning for the entire project. Yet, if the program is Adaptive in nature, it is impossible to prepare a project plan for the entire sub-project. When that is the case, the Program Manager must coach the sub-project leaders to develop high-level plans and create rough resource estimates to support those plans. It is not necessary to have precise estimates for the staffing management plan since the plan is based upon large pools of resources. It is far more importatnt for the Program Manager to know that they will need five more software development engineers during June and July than it is to know that they will be short by 6.3 engineers on Wednesday June 11.
Program Management Reviews
Program Management Reviews are used by the Program Manager to accomplish three things:
Check on the status of the sub-projects to determine if there are problems within them that are beyond the ability or authority of the sub-project leader to resolve
Ensure coordinated handoffs between sub-projects for joint or shared program deliverables
Identify risks between sub-projects and risks that are likely to migrate from one project to another
These reviews are normally scheduled to occur on a regular calendar schedule - such as the first and third Monday of each month. The reviews are attended by all of the sub-project leaders and key program stakeholders. The Program Manager normally starts the meeting with a quick overview of the status and near-term goals of the program to ensure alignment and then each of the sub-project leaders provides a status report of their sub-project. The sub-project leader reports focus on points of interface with other sub-projects and the reduction or elimiation of risk on their sub-project. These are not "activity reports" but rather are risk reviews. Formal minutes and action items should be maintained for these reviews and filed in the project archives.
