Christopher Global

For many organizations, portfolio management is the practice of an exec leader owning and managing a department, group of applications, or clients tied to a portfolio. The challenge with this portfolio management approach is understanding how to decompose scope into multiple execution levels to be structured sequentially on a roadmap. Leaders often approach this by establishing a roadmap of priority against business demands. However, this is an opportunity for a good portfolio manager to make a valuable impact. Let's dive into this a bit more in practical application.

When you decompose scope into products, services, or client deliverables, how clear is the scope of each effort? What is the confidence level in handling projects and programs in your team structure? Have you documented the differences between a portfolio (and sub-portfolio), program, or project? These differences are critical for clarity. Work at the project level is likely ready for the team to execute. You should be ready to provide project oversight and cross-functional coordination at the program level. At the portfolio level, you should be able to track and understand the status of cross-functional initiatives to report on organizational health. Sub-portfolios are as-needed, but projects, programs, and portfolios are standard in IT PPM or PMO context. Therefore, at each of these levels, you should have objectives clearly detailed at each level of management.

From a leadership perspective, you should be able to detail the purpose of each engagement quickly. Whether you use a reporting tool or write an email to your PMO leader, proper documentation lets you quickly find the business case (purpose), scope, acceptance criteria, and definition for each project, program, and portfolio. Many organizations don't detail this level of clarity in their standards. If your organization practices project governance, ask your leadership if they have documented the difference between the levels of project engagements. It's not uncommon for a project to suffer because it's too complex and cross-functional to be managed at the project level. Or for a program to be far too complex to be managed by one program manager. Therefore, understanding when you need to graduate a project to a program, split a program into multiple programs, or assign multiple program managers, is a necessary process to have documented. These documented processes, later turned into inputs for roadmap planning, significantly increase the chance that your team will build a roadmap that is 1) reflective of time + scope + resource availability and 2) prioritized against feasibility + technical complexity + urgency.