We often hear from customers that new Program Managers in their organization tend to behave very much like Project Managers that they once were. How we can make these folks “think and act like Program Managers”, they ask. A short answer is that these new Program Managers need
· An understanding of the core concepts of Program Management (including how it is different from Project Management)
· Experience in running actual programs
· Hand-holding & coaching support in their first assignment
Appreciating the difference between projects and programs is, of course, a key starting point for Program Managers to “think and act like Program Managers”. The definition of Program Management helps – that“a 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”.
Several examples could be cited keeping in mind the above definition.
But what is also useful is to graphically present the context of Program Management covering several component projects and its “touch points” downward with project management of those projects. “Touch points” or interfaces could also be upward – between Program Management and Program Governance (through a Program Review Board).
Understanding the above interfaces would significantly help Program Managers to “think and act” in line with stakeholder expectations. The typical interfaces of Program Management entail specific actions and are explained using the diagram below:
Part I: Program Management – Project Management interfaces (I1-I7)
I-1 Defines (program/projects)
The Program Manager defines component projects as part of the process of defining the overall program, how these component projects would contribute to program benefits and the oversight to be provided by the Program Manager for each of the projects. “Stitching” the various projects together in their contribution to each other and to the program is a distinguishing aspect of the Program Manager role.
I-2 Initiates (program/component projects)
Part of the definition above is also the scheduling the start and end of component projects. The Program Manager determines this on the basis of inter-project dependencies and other scheduling considerations such as business imperatives, resources, available time and optimal concurrency. Project closure is also as important as initiation since the Program Manager has to ensure that the project deliverables have met the acceptance criteria towards contribution to program benefits.
I-3 Manages/Approves (changes as appropriate)
Changes may arise from individual projects that may need approval by the Program Manager. Of course, it is not as if that all project changes need such an approval. As part of the program-project interface definition (described above), the Program Manager and the Project Manager need to agree on the change attributes that would necessitate Program Manager’s approval. These attributes could be based on effort, schedule, quality and risk parameters and impact on program goals (low, medium or high).
Another aspect of change management from a Program Manager point of view is to assess how changes in one component project may have a direct impact or bearing on another project. So, a project change potentially could send ripples of change in many other projects. It is the Program Manager’s job to make sure that these are identified and managed effectively (communication, impact analysis, re-planning etc.). Some changes may be so significant that they may need approval from the Program Review Board. The Program Manager is responsible to manage these as well end-to-end.
I-4 Monitors (component projects)
The monitoring of component projects by the Program Manager is quite different from tracking at a project level. The Program Manager is primarily concerned with those project milestones which would indicate how well the project is progressing relative to the plan and whether critical intermediate deliverables provide the confidence that the project will indeed contribute to program benefits as envisaged. The key theme here is for the Program Manager to let the Project Managers do their job and not micro-manage them.
The Program Manager needs to monitor benefits realization unlike the Project Manager whose primary focus is on his project deliverables. For example, in a program to set up an online retailing business, one of the projects could be to establish a call centre for assistance to online customers. A project deliverable could be the user documentation & training for the call centre staff. The associated benefit at a program level is the ramp-up speed of the call centre staff in using the software (in turn, having a bearing on the online retailing going live as planned in the program). This is an example of operational improvement as a benefit. Other typical benefits would be in the area of larger market share, improved customer service/experience, enhanced financial performance and so on.
I-5 Engages (with stakeholders)
In large programs, the Program Manager engages with many stakeholders, often across many organizations (customer, internal management, partner organizations, vendors, regulators etc.) – much more than a Project Manager typically does. However, the Program Manager needs to distinguish between project stakeholders and program stakeholders and let the Project Manager manage his project stakeholders. For example, in a program for a new software product initiative, the Head of Product Engineering responsible for the final integration of deliverables from multiple projects is a program stakeholder than a project stakeholder. Head of Sales & Marketing responsible for product launch & sales promotion would also be a program stakeholder and not a project stakeholder. In contrast, a component supplier for a project is a project stakeholder and not a program stakeholder.
I-6 Manages (program risks)
Risk Management at a project level is an input for risk management at a program level. The Program Manager needs to focus on those project risks which are potential threats for program goals and benefits realization. Other risks remain purely project risks for the respective Project Managers to address.
In addition, the Program Manager needs to address new categories of risk typically not addressed by the Project Manager – such as risk of regulatory changes, risks in the business environment, risks in funding and so on.
In some cases, some projects may finish earlier than others and their deliverables may be transitioned to production/operations to realize benefits in an incremental fashion. In such cases, operational risks need to be addressed as well by the Program Manager – something that the project manager is usually not concerned with.
Overall risk management needs strong collaboration between the Program Manager and the Project Managers of component projects. It would be very useful for the Program Manager / Program Management Office to set some common guidelines for risk management practice applicable for all projects.
I-7 Manages (inter-project dependencies & issues)
Managing inter-project dependencies may be arguably the most important aspect of the Program Manager’s job. While individual Project Managers need to take into account these dependencies (both up-stream and down-stream), it is ultimately the accountability of the Program Manager to see that all the independent projects are in sync. This needs constant vigil as, oftentimes, Project Managers may get engrossed in their own projects and miss the early warnings on a critical “external” dependency.
Sometimes, cross project issues could assume significant proportions – for example, contention for a critical resource (examples are a domain specialist or a testing platform) between two projects would need the active involvement of the Program Manager for resolution.
Part II: Program Management – Program Governance interfaces (G1-G7)
Programs are often complex endeavours to achieve strategic objectives of the organization. Such programs cannot be managed just by the Program Manager & Project Managers alone. Program Governance is the mechanism that provides high level direction, monitoring and support to the program and program manager – usually through a Governance Board comprising senior stakeholders from various functions and organizations involved in the program.
Typical Program Management – Program Governance interfaces are described below.
G1. Sets up (program governance)
The Program Manager often plays a key role in actually defining Program Governance tailored to the program – including the roles & responsibilities, constituents, meeting frequency, reporting, approval responsibilities etc. He also finds a place in the Governance Board typically as a co-ordinator. A Project Manager in many cases has no such direct participation in governance.
G2. Reports (to the Program Review Board)
The Program Manager assumes the primary responsibility for all reporting on the program to the Review Board – on a regular basis as defined in program definition as well as to respond to ad-hoc requests for information.
G3. Directs
The Review Board may, from time to time, provide directions to the program due to, say, changes in the business environment, changed priorities, contingencies etc. The Program Manager needs to ensure that these directions are translated into project requirements / project change requests and communicated to Project Managers for implementation.
G4. Monitors
The Program Manager needs to help define the mechanisms for monitoring by the Review Board (meetings, documents, presentations, participation etc.) and ensure that the Review Board receives accurate and timely information (enabling the Review Board to effectively direct the program).
G5. Escalates
The Program Manager needs to escalate issues to the Review Board as needed and receive support/direction for resolution.
G6. Approves
The Program Manager needs to ensure that necessary approvals are received from the Review Board – in situations such as significant change requests at a program level, initiation & closure of projects and exiting milestones in the stage-gate process etc.
G7. Supports
The Program Manager needs to effectively leverage the Review Board for optimal support so that the program achieves its goals and benefits.
In summary, interactions between program management & project management processes can be complex and dynamic. We have presented a simplified picture of the interfaces of Program Management as a primer or first step in appreciating the role of a Program Manager and being effective at it.
If you have comments on this article and/or experiences to share in ramping up to the role of a Program Manager, feel free to reach us at info@pm-powerconsulting.com. We value your inputs.
