Portfolio or Program or… Hybrid?

Background is always the same 

A few times I was assigned to the role of Program Manager or Portfolio Manager with one main goal: organize or improve a group of different projects and make them manageable and reported to the customer in an organized way. One time it was internal tower reorganization, another time it was Projects’ Portfolio for an external customer. In both situations I was wondering how I should start and which of the two concepts: Portfolio Management or Program Management should be used to manage that situation. 

Was it a Program? 

A whole group of dozens of projects with outputs dedicated to the same organization/customer with common resources and the same main stakeholders could be treated as a huge Program with different tracks generating future benefits. From that perspective it looks OK but… I didn’t have a defined end date, scope, or budget for that “Program” because new projects were continuously requested by the customer and sometimes even internally by my organization. The budget was growing accordingly to the size of new projects. The end date was extended every time a new, longer project appeared. How should I manage unpredictable scope, time and budget from Program perspective? Maybe it was not a Program itself and a different attitude should be taken? 

Was it a Project Portfolio? 

Looking from the Project Portfolio perspective there were some analogies to Portfolio Management. We reported summarized Total Contract Values, revenues, backlog of time and material projects in progress divided into the future months. We predicted future incomes and overall costs for all projects in scope and for the pipeline of proposals. We adjusted the number of needed Project Managers up to predictions to optimize costs. We were prioritizing projects to be more and more effective but still, we needed to go deeper into projects level to agree changes with customer’s counterparts, to report the whole projects during monthly meetings with the Customer Portfolio Manager. We couldn’t optimize the company profits adjusting the numbers and sets of projects, as Portfolio Management used to do. We couldn’t reject any new customer project even when we knew that it was less profitable than other projects because we were obliged by the customer frame agreement. 

Hybrid approach could be a solution 

I decided to mix Program Management and Portfolio Management approaches and I chose the most useful elements from both concepts. It was a good decision which let me control and organize all projects and satisfy both the customer and my own organization. Sometimes such a hybrid was called a Portfolio, sometimes a Program. I will use the Portfolio naming convention in my below elaboration. How did I organize that Hybrid? 

Defined and separated decision levels 

The whole Portfolio was divided by different decision levels: Strategic, Operational from Portfolio perspective and Delivery Level from Project perspective (see Figure 1). Every level has a different purpose and was managed in a different way.

Portfolio Strategic Level was dedicated to Portfolio Board and Senior Management. Strategic decisions were made based on financial predictions and reporting delivered by Portfolio. Sometimes that decisions were causing frame agreement changes. Sometimes new services or additional project scope were negotiated with the Customer. It was the highest level of escalations defined in the Portfolio. Customer Account Executive, Account Delivery Executive, Service Delivery Manager and Portfolio Manager were the main players on that level. Portfolio Board Meeting with presentation of Portfolio Highlight Report (HLR) was organized bi-weekly by the Portfolio Manager.

Portfolio Operational Level was organized for Portfolio Core Team (inc. Portfolio Manager, Track Project Leaders, PMO). Track Dashboards were presented by Track Project Leaders to the rest of audience on weekly basis. Track Project Leaders were established in Portfolio to control, manage and support specific kind of projects usually dedicated to one Service Tower, separate IT Service or sometimes for specific Customer.

Project Strategic Level was covering all relevant project strategic needs. There were Project Board Meetings organized with Project Highlight Reports presented by Project Managers to Project Board (inc. Project Executive, Senior User, Senior Supplier) on weekly or bi-weekly basis. That level was covering also Project Dashboard Reporting prepared by Project Managers to update Track Dashboards on weekly basis.

Project Operational Level was defined to organize work of Project Core Team (Project Manager, Architects, Engineers, Testers, etc.). There were usually weekly or more frequent meetings organized by the Project Manager with Project Core Team Members. Project Reporting was organized usually as Minutes of Meeting (MoM) containing the same parts as Project Dashboard Report. 

Project Delivery Level is the lowest decision level but very important for Project execution. Checkpoint reporting should be defined between reporting lines of the Project Core Team Member and the Project Manager. The format and the frequency are defined individually per work package or task. There is no central repository for this kind of reports because in many cases that might be a simple conversation with a task assignee.

Portfolio Management Strategies

To manage a Portfolio in an organized way there were defined and developed Portfolio Management Strategies with the most needed aspects of Portfolio, Program and Project Management. Strategies were guides for Project Managers on how they should manage projects in the Portfolio.

Communication Management Strategy

The Communication Management Strategy contained a description of the means and frequency of communication to related parties, both internal and external. It described how an effective communication within the Project’s team and with stakeholders was organized. It facilitated engagement with stakeholders through the establishment of a controlled and bi-directional flow of information.

Definition and description of internal and external communication aspects on all decision levels included:

• Portfolio organization structure with decision levels description,
• Communication procedure,
• Tools and techniques (Portfolio on-line workspace / collaboration site, collaboration site community, meeting notes, contacts, yellow pages),
• Reporting (Portfolio Highlight Report, Track Dashboard, Project Highlight Report, Project Dashboard Report, Project Reports, Exception Reports, etc.) – templates are defined and available for the whole Portfolio Team,
• Records (Minutes of Meeting, reports, other important records),
• Timing of communication activities (Project and Portfolio meetings overview, formal announcement, communication effectiveness reviews),
• On-line workspace (folders structure, access levels).

Risk Management Strategy

This document defined how risks would be managed during the lifecycle of the project and on Portfolio level. It defined the process, related techniques and standards which had application in projects, as well as responsibilities within the process.

The risk management procedure consisted of the following steps that were essential to manage risks effectively: identification, assessment, response planning and implementation. During the whole process, the communication was the key item covering all steps of the procedure.

One of the most important topics in Risk Management was Risk Tolerance – Risk Appetite. Usually it was set on 10% or 15% level of overall budget and time.

Portfolio supported projects with one central Risk Register which was available online on the Portfolio collaborative workspace.

Issue and Change Management Strategy 

The Issue Management Strategy defined activities and rules to manage and control issues that arise during the project.

An issue for the Portfolio was defined as a: RFC (Request for Change), problem/roadblock, off-specification, question, concern and any other matter which impacted the project covered by the Portfolio.

This Issue Management Strategy was designed to:

• outline the recommended approach for identifying issues and tracking the progress, documentation, and resolution of those issues, 
• facilitate attention to key issues impacting the Project,
• ensure all stakeholders are informed about the issue and, if applicable, participate in the resolution,
• create an audit trail of discussions and resolutions of Project issues.

Project Manager was the single point of contact for all project issues. All major issues were registered in central Issue Register which was available online on the Portfolio collaborative workspace. 

The Project Manager made decisions at the operational level of the project. If a decision required the Portfolio Manager/Project Executive or Project Board involvement (Strategic Level), an exception report had to be produced and communicated by the Project Manager to that decision bodies.

The table below shows which stakeholder is responsible for which decision:

Budget Management Strategy

The Budget Management Strategy was a governance component of the Portfolio. This method of working described how costs should be planned, structured and controlled. The strategy clearly defined how the costs on a project would be managed throughout the project lifecycle. 

The strategy set the format and standards by which the project costs were measured, reported and controlled. Earned Value Management (EVM) was used in the Portfolio to measure projects’ performance.

The Budget Management Strategy:

• identified who was responsible for managing cost within which tolerances,
• identified who had the authority to approve changes to the overall project’s budget,
• how cost performance was quantitatively measured and reported upon,
• reported format, frequency and to whom these were presented.

Project Cost Management included the processes required to ensure that the project was completed within an approved budget. Project Managers had to make sure that their projects were well defined, had accurate timeline and cost estimates and had a realistic budget. 

Quality Management Strategy

The Quality Management Strategy was used to define the quality techniques and standards to be applied and the various responsibilities for achieving the required quality levels during the project.

Quality Management ensured that right products are delivered by the projects defined in the Portfolio. 

Each project in the Portfolio used product-based planning technique which supported quality management by leveraging product descriptions. A product description was short information explaining what the purpose of the product was, what was its composition, and it treated also about quality aspects. The quality management procedure was built around the product-based planning technique.

The level of details of product description was determined between Project Manager and Project Board.

Beside the product description, the quality control was made in conjunction with Quality Register. There was a central Quality Register for the Portfolio established.

Scope, Schedule and Configuration Management Strategy

That document included 3 strategies in one place:

• Scope Management Strategy,
• Schedule Management Strategy,
• Configuration Management Strategy.

The Scope Management Strategy detailed how the project scope would be defined, developed, and verified. It clearly defined who was responsible for managing the projects’ scope and acted as a guide for managing and controlling the scope. The strategy provided the scope management framework for projects in the Portfolio and documented the scope management approach, roles and responsibilities as they pertained to project scope, scope definition, verification and control measures.

The Schedule Management Strategy provided guidance on how to develop, manage, and control the schedule throughout the project life cycle within the Portfolio. It presented required steps and techniques used. The strategy identified the process and procedures used to manage the schedules. In addition to defining the schedule development approach, that strategy defined who was responsible for tracking and reporting schedule progress, how schedule updates were received and incorporated, how to baseline the schedule. 

The Configuration Management Strategy was used to identify how, and by whom, the project’s products/deliverables (documents, infrastructure components, etc.) would be controlled and protected. The project configuration was all tangible and intangible deliverables/products. The Portfolio provided tools and template for project in scope.

The question from the topic is coming back like a boomerang with every new assignment. I decided to manage that Hybrid that way. Maybe it could be done differently?