Program Management Tools &amp; Techniques

Program Management is often view as project management on steroids. However, when this is the approach of the Program Manager, both the program and the program team usually suffer. Effective program management requires a different skill set.

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 project that normally costs millions of dollars. It 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.

Introduction to Program management tools

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. 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. It is involve in the oversight and risk resolution activities within each sub-project.

Ideally, the Program Manager is an experience 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. Use of Interface Control Documentation to manage the scope interfaces between sub-projects. The use of Milestone Alignment charts for schedule integration between projects. A use of a Staffing Management Plan for personnel resource alignment, and Program Management Reviews for program control.

As mention on the Project Team Leadership page, two vitally important characteristics of successful program management are communication skills and risk management.

Tools & techniques

Other tools and techniques that are discuss 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 apply 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. The considers all of the need 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 different 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 regulatory requirements. Each of these sub-projects are very different in terms of the scope of work and the need technical skills.

Sub project management

Yet each of these sub-projects must complete their sub-project goals to an overall program schedule. Integrate with the other sub-projects so that the new product can be successfully launch in the new market. The Systems Engineering discipline translates the overall program goals into detail sub-project requirements.

In addition, the Systems Engineering activities will establish quality attributes and success criteria for the sub-project deliverable that will ensure the overall program is able to meet the program quality and success criteria.

The definition of requirements and tracking of successful attainment of the requirements is often maintain in a Systems Engineering Management Plan. The SEMP will contain the Trace-ability Matrix (discuss on the Scope Planning page) for each of the sub-projects. Often there is a significant amount engineering analysis need to establish the performance and life cycle requirements for aspects of the system. That are effect by multiple sub-projects.

This analysis can take weeks or months to complete, yet it is a crucial portion of the overall program life cycle and must be done prior to the initiation of the sub-projects.

Interface Control Documentation

Interface Control Documents (ICDs) are the mechanism use to communicate technical requirements and interfaces between sub-project teams. These must be manage 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 document on ICDs are mechanical interfaces, electrical interfaces, acceptable tolerances. Data Stream 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 list.

The development of ICDs is often as much political as it is technical.

One of the sub-projects is task with creating an initial draft ICD that is then review and comment upon by all of the affect 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 control document and, when working with multiple companies, placing the ICD on the contract as a controlled document.

Milestone Alignment Schedule

The Milestone Alignment Schedule is the Program Manager's schedule integration tool. This schedule takes the major sub-project milestones from each sub-project and carries them onto a program schedule. In addition to the major milestones, I normally include any hand off activities between sub-projects. Such as a pilot run of the new product in the new factory. I have found this to be a better program schedule for the Program Manager than using multi-project software and integrating all of the sub-projects. On a fairly large program, the multi-project software will quickly expand to include literally thousands of activities as each of the sub-project plans are incorporate.

Sifting through all of these activities to identify and highlight the vital few becomes a time-consuming task for the Program Manager. Instead, when the sub-projects are initiate the Program Manager defines the schedule integration points that he or she wants to track. Then during the ongoing Program Reviews, the Program Manager tracks those milestones and in the risk identification portion of the review, new integration points are identified and added when appropriate.

The type of schedule can be create in a Gantt chart format where each integration milestone is a line on the Program Gantt or it can create as a pipeline chart where each of the sub-projects is a pipe and the integration milestone linking the pipelines are shown. I have use both approaches and both are acceptable. The example shown is a pipeline chart.

Staffing Management Plan

The staffing management plan is use by the Program Manager to optimize the resource pools. That are share 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 detail 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 base upon large pools of resources.

Program Management Reviews

Program Management Reviews are use 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 coordinate hand offs between sub-projects for joint or share program deliverable
Identify risks between sub-projects and risks that are likely to migrate from one project to another
These reviews are normally schedule to occur on a regular calendar schedule - such as the first and third Monday of each month.

The reviews are attend 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. 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. The reduction or elimination of risk on their sub-project. These are not "activity reports" but rather are risk reviews. Formal minutes and action items should be maintain for these reviews and file in the project archives.