PMI PgMP – The Program Management Summary

1. Introduction

This section summarizes all the previous sections to help you in recapping the important subjects discussed until now and to highlight some areas that need your attention. In this section, we will review the following topics the Program and the Program management. The program five management domains the Program management Supporting processes and we’ll highlight the aggregated program artifacts.

2. Program and Program Management

The program is a group of related projects, subprograms and program activities managed in a coordinated way to obtain benefits not available from managing them individually. The subprogram is a program that is managed as part of another program. The program component may be a project, a subprogram or a group of other work within the program. There are dependencies and integration between the program components to achieve the program objectives and realize the blend benefits. We reviewed also the three different offices. The Project Management office, the Program Management office and the Portfolio Management office.

We concentrated more on the Program Management Office and its given responsibilities. The Program Management Office may have one person or more depends on the size and the structure of the program and the responsibilities given to the Program Management Office. We highlighted the different program structures, the simple program structure where we have only projects, the regular program structure where we have projects and Program Management Office and a complex program structure that has sub programs in addition to the projects and the Program Management Office as shown in this chart. Practical example of the roles and responsibilities of the three different program structures was provided to complete the picture.

The program management is the application of knowledge, skills, tools and techniques to a program to meet the program requirements and to obtain benefits and control not available by managing components individually. So it is a way that you use to manage all program components in a higher level to achieve the program goals and objectives. Program management is different than project management in some dimensions, including the uncertainty level, handling the required changes, the complexity and the success measurements. The program management has five major dimensions to manage the program and measure its performance, which are the program lifecycle management, the program strategy alignment, the program benefits management, the program stakeholder engagement and the program governance.

3. Program Management Domains

We reviewed the different phases of the program lifecycle domain which were the program definition phase, the program benefits delivery phase, and the program closure phase, and we reviewed the sub phases for each of the three phases as following the program definition phase has program formulation and Program preparation sub phases. The program benefits delivery phase has component planning and authorization, component Oversight and Integration, and Component transition and closure sub phases. The program closure phase has program transition and program close out sub phases. The program definition phase and the program closure phase are executed once on the program level, but the program benefits delivery phase is repeated with each program component, which may be a project or a subprogram. Remember that practically these phases and sub phases are not discrete, but they are continuous and interlink. For instance, to have a successful program closure, you have to start early to blend for the program closure phase, maybe during the program planning activities and the component planning activities, you should define clear program scope, strong acceptance criteria for the different types of deliverables, high quality standards, clear vendor contract terms, and many other important aspects.

We then pointed the program lifecycle management interactions with the component management for the project and the subprogram components. The program components will have different start and end dates based on the program roadmap. We outlined also the relation between the portfolio management and the program management. We described many of the artifacts shown in this chart during the previous sections, and we attached it a template or an example for some of them, including the program business case, the program, charter the program, roadmap the program. Management plan with many of the subsidiary plans. Stakeholder engagement plan, stakeholder register. Stakeholder map benefits. Realization plan benefits. Register program schedule and program risk register. We reviewed the program Benefits Management Domain phases which are benefits identification, benefits analysis and planning, benefits delivery, benefits transition and benefits sustainment.

We noted that the Benefits analysis and Planning and Benefits delivery are repeated with each program component, but the benefits identification, the benefits transition, and the Benefits sustainment are executed once on the program level. We reviewed all of these artifacts and then went into more details for the benefits register and the benefits realization plan. The benefits register is created in the benefits identification phase and then updated in the benefits analysis and the planning and benefits delivery phases. The benefits realization plan is created in the benefits analysis and the planning phase and then updated in the benefits delivery phase. Remember that we will need to create a business case in the Benefits sustainment phase for a new project or program that may be required to resolve a post production issue or to recover a failure in sustaining the realized benefits. We reviewed also the activities for each phase of the program benefits management domain.

We got some highlights regarding the transition activities and regarding the timing relation between the program lifecycle management and the benefits realization management. We reviewed the program strategy alignment domain elements, which are the organizational strategy and program alignment, the program roadmap and the environmental assessments. The three elements constitute the program strategy alignment are almost addressed in parallel and not one element after the other, like the previous two domains program lifecycle and program benefits management.

We reviewed these artifacts and then went into more details for the program business case, program plan and Program Road Map, where we got some examples for the different representations of the program roadmap. Remember that the program roadmap is a chronological representation of a program’s intended direction, graphically including measure, delivery and milestones. We reviewed also the activities of the program strategy alignment to domain elements. We got some highlights regarding the relation between the organization strategy and the program strategy, where we outlined the connections from the organization vision, mission and strategies down to the portfolios programs, projects and operations.

We highlighted also the timing relation between the program lifecycle management and the program strategy alignment. We reviewed the program stakeholder engagement domain elements, which are the program stakeholder identification, the stakeholder engagement planning, and the stakeholder engagement. We reviewed some examples for the internal and external stakeholders. We reviewed also the major artifacts of the program stakeholder engagement and then went into more details for the Stakeholder Register Stakeholders Map, which guides you to deal with the stakeholders based on his power and interest and then the stakeholder engagement plan.

We reviewed also the activities of the program stakeholder engagement domain elements, and we highlighted the timing relation between the program lifecycle management and the program stakeholder engagement. We reviewed the program governance domain elements, which are governance board formation, governance planning, and governance adherence. Program Governance looks like the umbrella covering the program management or as a doctrine with respect to the laws. We reviewed also the major artifacts of the program governance and then elaborated more on the governance board, its responsibilities and the program governance plan. We studied the differences between the program audit, program review, and program health check. The program Audit answers the question are we doing it right?

The program Review answers the questions where are we up to the Health check verifies a specific deliverable from technical or business standpoint. We understood that the report generated from any of these retools would help the management to make decisions, to recover the current situation, to apply changes, or to move forward. We also reviewed in another section the benchmarking, which involves comparing actual or blend program practices to those of comparable program to identify best practices, generate ideas for improvement, and provide a basis for measuring performance. We reviewed also the activities of the Program governance domain elements, and we highlighted the timing relation between the program lifecycle management and the program governance. We added also some hints regarding the Program management office.

This chart explains the timing relation between the five domains altogether. We can notice the following the organizational strategy and program alignment started before the program started, which include the program business case or the program feasibility study. Then, in the program definition phase, during the program formulation and program preparation, the benefits identification will be executed and the benefits analysis and planning will start. For the program components, the organizational strategy and program alignment will continue until completion. The program roadmap will be executed and the environmental assessments will start. The program stakeholder identification will be executed and the stakeholder engagement planning will start. The governance board formation will be executed and the governance planning will start.

Coming to the program benefits delivery phase during the component planning and authorization, component oversight and integration and component transition and closure, the benefits analysis and the planning will continue until completion. For the program components, the benefits delivery will be executed for the program components and the benefits transition will start. The environmental assessment will continue, the stakeholder engagement planning will be completed and the stakeholder engagement will start. The governance planning will continue until completion and the governance adherence will start. And finally, in the program closure phase during the program transition and the program close out, the benefits transition will continue until completion and the benefits of will start. The environmental assessment will continue until compilation. The stakeholder engagement will continue until completion. The governance adherence will continue until compilation. After the program is closed, the benefit sustainment will continue to assure the continuity of the delivered benefits as bear the benefits sustainment plan.

4. Program Management Supporting Processes

The program management supporting processes are very similar to the processes at the project, but they address considerations of a higher level. The program management supporting activities aggregate the information from the component level to reflect a program perspective. This chart acts like a map between the program management supporting processes and their activities for the different existing nine groups and the program lifecycle management domain phases. The program management supporting activities groups are nine groups and are shown in the left to last column of this chart which are the program communication management, the program financial management, the program integration management, the program procurement management, the program quality management, the program resource management, the program risk management, the program schedule management and the program scope management.

The program lifecycle management domain phases are shown in the upper row of this chart which are the program definition phase, the program benefits delivery phase and the program closure phase. From this chart, we notice that only the program financial management, the program integration management, and the program procurement management span over the three program lifecycle phases, but the rest of the supporting activities groups span over the program definition phase and the program benefits delivery phase. The major activities listed in the map has sub activities or outputs or both of them which were detailed in the previous section.

When reviewing this brief map, we will notice that in the program definition phase, the following activities, which are related mainly to the initiation and planning of the different groups are executed the communications planning the program cost estimation, the program financial framework establishment the program financial management plan development the program initiation, the program management plan development the program infrastructure development, the program procurement planning the program quality planning, the resource planning, the program risk management planning, the program schedule planning and the program scope blending.

Then in the program benefits delivery phase the following activities which are related mainly to the execution and monitoring and controlling of the different groups, are performed the information distribution the program performance reporting the component cost estimation the program cost budgeting the program financial monitoring and control the program execution or delivery management the program performance monitoring and control the program procurement the program procurement administration the program quality assurance the program quality control the resource prioritization the resource interdependency management the program risk identification the program risk analysis the program risk response planning the program risk monitoring and control.

The program schedule, control and the program scope, control. And finally, in the program closure phase, the following activities which are related mainly to the closing of the different groups are executed the program financial closure, the program transition and benefit sustainment the program closure and the program procurement closure.

5. Aggregated Program Artifacts

Many of the program artifacts are created based on the aggregated information from the program components. Some of these artifacts are listed here and we are going to elaborate them more starting with the program management plan and its subsidiary plans. The information here is aggregated from the different program components, so you will find in the arrow starting from the component level towards the program level. On the other hand, the program sets some guidelines to the component level mainly through its governance plan. So we will have another arrow starting from the program level towards the project level. The only exception is the governance plan, which is coming only from one direction, which is from the program level to the project level.

For instance, the program scope is gathered from the different components and at the same time it is governed by the rules established at the program level. And the communication management plan may have weekly meeting defined at the program level that will be applied at the component level and may have some stakeholders information defined at the component level that should be elevated to the program level. Regarding the program issue register, it contains issues gathered from the component level and others created on the program level which are mainly related to the component integration and the program level management, like the steering meetings, the risk analysis sessions, the program audit reports, the program sustainment plan and so on. Similarly, the risk register contains risks gathered from the component level and others created on the program level.

Remember that the risk is regarding an event in the future, but the issue is regarding an event happened already or is happening now. We can say that the issue is a risk with 100% probability. This chart briefs the program master time schedule contents, which are mainly aggregated from the different program components.

These contains are measured deliverables and milestones from the program components, which are the projects and the subprograms within the program structure, the major integration activities between the program components, the program transition and closure activities, and other program activities like the steering meetings, the risk identification and analysis sessions, the program review or audit, and so on.

This chart shows how the program benefits are realized as the sum of its components benefits. Some of these benefits may be incrementally realized during the program execution and others may be realized at the end of the program. Program work breakdown structure is a collection of all the components work breakdown structure in addition to the work breakdown structure related to components integration, program management, and program transition and closure, this chart describes this relation between the program work breakdown structure and the component work breakdown structure. A program constraint is a program limitation.

It is referring to a condition stated for the program that if found to be wrong, it will be more beneficial for the program. For instance, the program budget is a constraint and the staff working hours is another constraint. A program assumption is referring to a supposition guest for the program that if found to be wrong, it will have a negative impact on the program. Assumptions can be defined also as factors that for planning purposes are considered true, real or certain. For instance, in a financial management system, one assumption may be the ability of the local bank systems to accept and process the payroll data based on the Excel file format. And another example for the assumption in the inventory management system is having electronic format of the inventory items left to be able to upload them to the inventory module and avoid data entry.

This chart shows how the program constraints and assumptions are created on the program level. Some of the constraints and assumptions are elevated from the component level to the program level, while others are created on the program level. Most of the constraints and assumptions created at the program level are related to the components integration, resource management, and contractual management, and some of them are related to the organization and environments around the program. This chart shows how the program decision requests are raised on the program level and how the status reporting is compiled on the program level.

Some of the decision requests that are elevated from the component level to the program level are not resolved by the program manager and should be escalated higher for decision making, while some other decision requests are created on the program level and need higher level as steering committee to make the decision. When raising a decision request, the program manager should prepare options for the decision with enough explanation and if possible, a recommended decision as well.

This should facilitate the decision and increase the confidence in the program management team. To combine the program status, we need to gather component status reporting and then we will select the important items with respect to the program level. Moreover, the component integration status and the other items on the program level such as program financial and benefits realization, are also prepared for the required program status reporting.

6. Conclusion

In this section we reviewed the following the definitions of the program and the program management the program v management domains where we went quickly through the major artifacts and measure activities. We mapped also all the five domains together and got clue on the measure activities of the different domains in each phase of the program life cycle. The program management supporting processes where we went quickly through the nine groups of activities as bear the phases of the program lifecycle and we highlighted the program artifacts and how they are aggregated from the component level to the program level.