The Agile Project Portfolio Management Framework Guide

You can read the guide online on this page or download a PDF version of the guide.

Get your Agile Project Portfolio Management Framework Guide

1. Purpose of this guide

The Agile Project Portfolio Management Framework (APPMF) is a framework for managing large and complex project portfolios. This guide contains the definition of the APPMF. This definition consists of the APPMF’s roles, events, artifacts, and the rules that bind them together.

2. Definition of the Agile Project Portfolio Management Framework

The Agile Project Portfolio Management Framework (APPMF) is a framework within which people can address complex portfolio management problems while productively and creatively delivering projects of the highest possible value. The APPMF works well with any project delivery method. From Scrum to Waterfall, and anything in between.

The APPMF does not involve making project-by-project choices based on fixed acceptance criteria. Instead, decisions to add or subtract projects from the portfolio are based on the three goals of the APPMF:

1. Maximize the value of the portfolio
2. Seek the right balance of projects, thus achieving a balanced portfolio
3. Create a strong link to strategy, thus the need to build strategy into the portfolio

Defining strategy needs to come before you start project portfolio management. In order to select the right set of projects to execute, the strategic goals must be defined in advance.

The APPMF is an adaption of the Scrum framework and shares many of the principles it was built upon. The APPMF, like Scrum, is:

- Lightweight
- Simple to understand
- Difficult to master

The APPMF consists of Portfolio Teams and their associated roles, events, artifacts, and rules. Each component within the framework serves a specific purpose.

The Agile Project Portfolio Management Framework

The rules of the APPMF bind together the events, roles, and artifacts, governing the relationships and interaction between them. The rules of APPMF are described throughout the body of this document.

Specific tactics for using the APPMF vary and are described elsewhere. For example, on our website: www.data-solutions.ch.

3. APPMF Theory

The APPMF is founded on empirical process control theory or empiricism. Empiricism asserts that knowledge comes from experience and making decisions based on what is known. The APPMF employs an iterative, incremental approach to optimize predictability and control risk. Three pillars uphold every implementation of empirical process control: transparency, inspection, and adaptation.

3.1. Transparency

Significant aspects of the process must be visible to those responsible for the outcome. Transparency requires those aspects be defined by a common standard so observers share a common understanding of what is being seen.
For example:

- A common language referring to the process must be shared by all participants; and
- Those performing the work and those accepting the work product must share a common definition of portfolio value.

3.2. Inspection

APPMF users must frequently inspect projects, APPMF artifacts and progress toward the three portfolio goals to detect undesirable variances. Their inspection should not be so frequent that inspection gets in the way of the work. Inspections are most beneficial when diligently performed by skilled inspectors at the point of work.

3.3. Adaptation

If an inspector determines that one or more aspects of a project or process deviate outside acceptable limits and that the resulting product will be unacceptable, the process or project being executed must be adjusted. An adjustment must be made as soon as possible to minimize further deviation.

The APPMF prescribes four formal events for inspection and adaptation, as described in the APPMF Events section of this document:

- Portfolio Planning
- Portfolio Review
- Portfolio Retrospective
- Daily Meeting

4. The Portfolio Team

The Portfolio Team consists of a Portfolio Owner, the Portfolio Committee, and—optional—a Project Management Office (PMO) Team. Portfolio Teams are self-organizing and cross-functional. Self-organizing teams choose how best to accomplish their work, rather than being directed by others outside the team. Cross-functional teams have all competencies needed to accomplish the work without depending on others not part of the team. The team model in the APPMF is designed to optimize flexibility, creativity, and productivity.

Portfolio Teams manage project portfolios iteratively and incrementally, maximizing opportunities for feedback. Delivery of the right projects ensures value for the organization and execution of its strategy.

4.1. The Portfolio Owner

The Portfolio Owner is responsible for maximizing the value of the portfolio, seeking the right balance of projects and creating a strong link to strategy. How this is done may vary widely across organizations.
The Product Owner is the sole person responsible for managing the Project Backlog. Project Backlog management includes:

- Clearly expressing Project Backlog items;
- Ordering the items in the Project Backlog to best achieve the three portfolio goals;
- Optimizing the value of the work the PMO Team performs;
- Ensuring that the Project Backlog is visible, transparent, and clear to all, and shows what projects the organization will work on next; and
- Ensuring the Portfolio Team understands items in the Project Backlog to the level needed.

The Portfolio Owner may do the above work, or have the PMO Team do it. However, the Portfolio Owner remains accountable.

The Portfolio Owner is one person, not a committee. The Portfolio Owner typically represents the desires of a Portfolio Committee in the Project and Portfolio Backlog, but those wanting to change a Backlog item’s priority must address the Portfolio Owner.

The reason for having a Portfolio Committee is that the decisions that need to be made usually cannot be made by a single person. For the Portfolio Owner and Committee to succeed, the entire organization must respect their decisions.

A Portfolio Owner should understand and monitor changes in the organizational strategy and objectives and be aware of how the portfolio supports them. Both financial and nonfinancial benefits and risks to the organization need to be taken into account.

The Portfolio Owner typically does not create organizational strategy and objectives but may participate in the process, depending on the specific organization. However, the Portfolio Owner does play a key role in creating the portfolio-strategic plan and implementing the strategy by monitoring the execution of projects in support of the plan and by communicating progress and results.

Portfolio Owners receive information on portfolio project performance and progress, and they convey to the Portfolio Committee how the Project Backlog items as a whole are aligned with the strategic goals, then provide appropriate recommendations or options for action.

They also ensure that timetables for portfolio management processes are maintained and followed and that the managers/owners of the Portfolio Backlog items (projects, programs, and operations) receive and provide the information required under the portfolio management processes.

The Portfolio Owner is responsible for ensuring the APPMF is understood and enacted. Portfolio Owners do this by ensuring that the Portfolio Team adheres to the APPMF theory, practices, and rules.

The Portfolio Owner is a servant-leader for the Portfolio Team. The Portfolio Owner helps those outside the Portfolio Team understand which of their interactions with the Portfolio Team are helpful and which aren’t. The Portfolio Owner helps everyone change these interactions to maximize the value created by the Portfolio Team.

4.2. The Portfolio Committee

Portfolio governance is established by a Portfolio Committee to make decisions about investments and priorities for the portfolio and ensures the portfolio management processes are followed to sustain the organization.

The Portfolio Committee is made up of one or more individuals with the requisite authority, knowledge, and experience to ensure the alignment of Portfolio Backlog items with organizational strategy.

The Portfolio Committee has the authority to make resourcing, investment, and priority decisions as needed.

Decisions include new Portfolio Backlog items, the suspension or change of existing Portfolio Backlog items, and the reallocation of resources among Portfolio Backlog items. The decisions may be complex with significant organizational constraints—especially concerning reallocation of resources.

4.3. The Project Management Office (PMO) Team

When managing the Project and Portfolio Backlog, as well as monitoring the projects in execution, is too much work for the Portfolio Owner, you can form a Project Management Office (PMO) Team. The PMO Team consists of professionals who do the work of categorizing and evaluation of the Project Backlog (see Artifacts). They also make sure that monitoring of the projects on the Portfolio Backlog is done and dashboards are up to date.

5. APPMF Events

Prescribed events are used in the APPMF to create regularity and to minimize the need for meetings not defined in the APPMF. All events are timeboxed events, such that every event has a maximum duration.

Other than the Portfolio Cycle itself, which is a container for all other events, each event in the APPMF is a formal opportunity to inspect and adapt something. These events are specifically designed to enable critical transparency and inspection. Failure to include any of these events results in reduced transparency and is a lost opportunity to inspect and adapt.

5.1. The Portfolio Cycle

The heart of the APPMF is a Portfolio Cycle, a timebox of one month or less during which projects on the Portfolio Backlog deliver value. Useable and potentially releasable product increments are created by the different projects. Portfolio Cycles best have consistent durations throughout the year. A new Portfolio Cycle starts immediately after the conclusion of the previous Portfolio Cycle.

Portfolio Cycles contain and consist of the Portfolio Planning, Daily PMO meetings, the monitoring and reporting work, the Portfolio Review, and the Portfolio Cycle Retrospective.

Portfolio Cycles are limited to one calendar month. When a Portfolio Cycle’s horizon is too long, the definition of what has value may change, complexity may rise, and risk may increase. Portfolio Cycles enable predictability by ensuring inspection and adaptation of progress toward the three APPMF goals at least every calendar month. Portfolio Cycles also limit risk to one calendar month of cost for each project.

5.2. Portfolio Planning

The projects that will stay, be added or removed from the Portfolio Backlog is planned at the Portfolio Planning meeting. Also, resource allocation and funding for these projects are decided on in this meeting. This plan is created by the collaborative work of the entire Portfolio Team.

Portfolio Planning is timeboxed to a maximum of eight hours for a one-month Portfolio Cycle. For shorter Portfolio Cycles, the event is usually shorter. The Portfolio Owner ensures that the event takes place and that attendants understand its purpose. The Portfolio Owner teaches the Portfolio Team to keep it within the timebox.

Portfolio Planning answers what projects should be on the Portfolio Backlog in order to:

1. Maximize the value of the portfolio
2. Seek the right balance of projects, thus achieving a balanced portfolio
3. Create a strong link to strategy, thus the need to build strategy into the portfolio

under the restraints of available people, skills, technology, the appetite for risk, and budget.

Topic One: Value

The first goal of the APPMF is maximizing the value of the portfolio. This means that each project should represent good value to the organization and the collection of projects must make efficient use of the resources available. Where projects compete for scarce resources, it must be clear how the allocation between them is to be made based on value.

There are many value evaluations that can be done for the projects on your Project Backlog. To name a few: Net Present Value, Return On Investment, Expected Commercial Value, Options Pricing Theory, Scoring Models and Check Lists. You should select more than one for your own evaluation strategy and compare their values during the Portfolio Planning Meeting. Preparing these evaluations and collecting all necessary data is the responsibility of the Portfolio Owner but typically have the PMO Team do this.

Topic Two: Balancing

Depending on your organization, there are many possible portfolio attributes that require balancing. But the one pair each organization should look at is risk and value.

The portfolio risk-value bubble chart represents a portfolio view of all (or a selection of) projects and puts projects into one of four quadrants based on value and risk; this is important for identifying projects that drive overall greater value to the organization compared to other projects as well as highlight projects that should likely be screened out.

One of the key benefits to a portfolio bubble chart is to quickly show the balance of the current portfolio. Using portfolio bubble charts the Portfolio Owner can focus conversations to help better manage the portfolio. When reviewing projects that are in the higher-value/lower-risk quadrant, the Portfolio Owner should ask the question: “How can we get more of these types of projects in the portfolio?” Likewise, with the lower-value/higher-risk projects, the Portfolio Owner should ask how to avoid those types of projects. These discussions will greatly enhance the management of the portfolio and enable the Portfolio Owner to “manage the tail” and ensure that only the best projects are selected and executed. See an example of a portfolio risk-value bubble chart below:


Topic Three: Strategy

Strategic fit is the first and easiest to envision because it addresses the question: “Are your projects consistent with your articulated strategy?” A simple example; let's take a company that has defined the following business strategy. I know it is a very boring one, but it will work for our purpose.

1. Expand globally. Existing markets are North America and Europe. The target market is Asia.
2. Be profitable.
3. Maintain our financial position.
4. Leverage success without leveraging assets.

You can translate this into the following strategic goals:

1. Market penetration
2. Return on Investment (ROI)
3. Low up-front investment
4. Use existing technology

Once strategic goals have been defined, which is itself a nontrivial process, linking them to the projects on your Project Backlog is relatively straightforward. Each project can be examined to see the extent to which it supports each of the strategic goals. This will be a key step in the Portfolio Planning Meeting. The goal is not to choose the 10 projects with the highest return on investment but to ensure that the Portfolio Backlog represents the strategic goals of the business.

With help from the Strategic Buckets Model, the Portfolio Team can decide on resource allocation. It answers the questions: “If this is our strategy, then how should we be allocating our funds and people?” It starts with strategic goals and then moves to setting aside funds or buckets of money destined for each strategic goal. The goal of the portfolio is to fill as many buckets as possible in order to create a strategically balanced portfolio.

Topic Four: Authorization

The Portfolio Backlog is updated as a result of decisions made by the Portfolio Committee during their formal or informal portfolio review meetings. For example, when the Portfolio Committee decides that a Portfolio Backlog item needs to be added, terminated, receive more funds, or changed in some other fashion, the Portfolio Backlog is updated accordingly. Once the Portfolio Committee makes a decision that changes the current Portfolio Backlog in some way, the decision is communicated to stakeholders, sponsors, and Portfolio Backlog item owner (Product Owner, Project Manager, or Program Manager). The method for documenting and communicating the governance decisions may be a spreadsheet, a text document, or found within the Portfolio Backlog. The formal decisions made in the Portfolio Review meeting and approved by the Portfolio Committee are called Portfolio Authorization.

5.3. Portfolio Review

A Portfolio Review is held at the end of the Portfolio Cycle to inspect the projects on the Portfolio Backlog and adapt the Portfolio Backlog if needed. During the Portfolio Review, the Portfolio Team collaborate about what was done in the Portfolio Cycle. Based on that and any changes to the Project Backlog during the Portfolio Cycle, attendees collaborate on the next things that could be done to optimize value. Stopping projects, accelerating projects, reducing or increasing budget, etc. These ideas and information will be used as input in the Portfolio Planning Meeting. This is an informal meeting, not a status meeting.

This is a four-hour timeboxed meeting for one-month Portfolio Cycles. For shorter Portfolio Cycles, the event is usually shorter. The Portfolio Owner ensures that the event takes place and that attendants understand its purpose. The Portfolio Owner teaches all to keep it within the timebox.

It may not be necessary to go into detail on all projects, but ensure that those projects in the Portfolio that are not delivering the expected value are followed up on. A process that includes all projects but only invests significant time in those projects that are off target is an exception-based review.

Exception-based reviewing means that only projects that pass a certain threshold are reviewed. For example, projects that exceed the budget by more than 10 percent, or are not delivering value for over two months, are highlighted and require a decision as to whether corrective action is needed. This saves time by not having to review all projects in a detailed manner, as the projects that are on track are not analyzed to the same level of detail. It also means that attention can be drawn to projects when problems occur, not necessarily when the review meeting happens.

The Portfolio Review includes the following elements:

- Attendees include the Portfolio Team and key stakeholders invited by the Product Owner. This could be, for example, the Project Manager or Product Owner of a project in trouble;
- The Product Owner explains what Portfolio Backlog items have been “Done”;
- The Portfolio Team discusses which projects went well during the Portfolio Cycle, which projects had problems, and how those problems were solved;
- The Product Owner discusses the Portfolio Backlog as it stands. He or she projects likely completion dates based on progress to date (if needed) and known risk and issues;
- The entire group collaborates on what to do next so that the Portfolio Review provides valuable input to subsequent Portfolio Planning;
- Review of how the marketplace or potential value of the projects might have changed, what is the most valuable thing to do next; and
- Review of the timeline, budget, potential capabilities, and marketplace for the projects in the portfolio.

The result of the Portfolio Review is a revised Portfolio Backlog that defines the probable Portfolio Backlog items for the next Portfolio Cycle. The Portfolio Backlog may also be adjusted overall to meet new opportunities.

5.4. Daily PMO Meeting

If there is a PMO Team, then there should be a Daily PMO Meeting. The Daily PMO Meeting is a 15-minute timeboxed event for the Portfolio Owner and the PMO Team to synchronize activities and create a plan for the next 24 hours. This is done by inspecting the work since the last Daily PMO Meeting and forecasting the work that could be done before the next one. The Daily PMO Meeting is held at the same time and place each day to reduce complexity. During the meeting, the Portfolio Team members explain:

- What did I do yesterday that helped the PMO Team to prepare for the next Portfolio Planning and Review Meetings?
- What will I do today to help the PMO Team be ready for the next Portfolio Planning and Review meetings?
- Do I see any impediment that prevents me or the Portfolio Team from a successful Portfolio Planning and Review Meeting?

The Portfolio Team uses the Daily PMO Meeting to inspect progress toward the Portfolio Planning and Review Meetings and to inspect how progress is trending toward collecting all information for these meetings. The Daily PMO Meeting optimizes the probability that the Portfolio Team has all necessary information to make the right decisions. Every day, the Portfolio Team should understand how it intends to work together as a self-organizing team to accomplish this. The PMO Team or team members often meet immediately after the Daily PMO Meeting for detailed discussions or to adapt or replan the rest of the Portfolio Cycle’s work.

The Portfolio Owner ensures that the PMO Team has the meeting, but the PMO Team is responsible for conducting the Daily PMO Meeting. The Portfolio Owner teaches the PMO Team to keep the Daily PMO Meeting within the 15-minute timebox.

Daily PMO Meetings improve communications, eliminate other meetings, identify impediments to development for removal, highlight and promote quick decision-making, and improve the PMO Team’s level of knowledge. This is a key inspect and adapt meeting.

5.5. Portfolio Cycle Retrospective

The Portfolio Cycle Retrospective is an opportunity for the Portfolio Team to inspect itself and create a plan for improvements to be enacted during the next Portfolio Cycle.

The Portfolio Cycle Retrospective occurs after the Portfolio Review and prior to the next Portfolio Planning. This is a three-hour timeboxed meeting for one-month Portfolio Cycles. For shorter Portfolio Cycles, the event is usually shorter. The Portfolio Owner ensures that the event takes place and that attendants understand its purpose. The Portfolio Owner teaches all to keep it within the timebox. The Portfolio Owner participates as a peer team member in the meeting from the accountability over the APPMF process.

The purpose of the Portfolio Cycle Retrospective is to:

- Inspect how the last Portfolio Cycle went with regards to people, relationships, process, and tools;
- Identify and order the major items that went well and potential improvements; and
- Create a plan for implementing improvements to the way the Portfolio Team does its work.

The Portfolio Owner encourages the Portfolio Team to improve, within the APPMF process, its development process and practices to make it more effective and enjoyable for the next Portfolio Cycle. During each Portfolio Cycle Retrospective, the Portfolio Team plans ways to increase the quality of their decision by adapting the collected information as appropriate.

By the end of the Portfolio Cycle Retrospective, the Portfolio Team should have identified improvements that it will implement in the next Portfolio Cycle. Implementing these improvements in the next Portfolio Cycle is the adaptation to the inspection of the Portfolio Team itself. Although improvements may be implemented at any time, the Portfolio Cycle Retrospective provides a formal opportunity to focus on inspection and adaptation.

6. APPMF Artifacts

The APPMF’s artifacts represent work or value to provide transparency and opportunities for inspection and adaptation. Artifacts defined by the APPMF are specifically designed to maximize transparency of key information so that everybody has the same understanding of the artifact.

6.1. Project Backlog

The Project Backlog is an ordered list of all projects that might be needed in the organization and is the single source of projects for any changes to be made in the organization. The Portfolio Owner is responsible for the Project Backlog, including its content, availability, and ordering. The inputs come from the organization’s Demand Management process.

A Project Backlog is never complete. The earliest development of it only lays out the initially known and best-understood projects. The Project Backlog evolves as the organization and the environment in which it operates evolves. The Project Backlog is dynamic; it constantly changes to identify what the organization needs to be appropriate, competitive, and useful. As long as an organization exists, its Project Backlog also exists.

The Project Backlog lists all projects, ideas, proposals, enhancements, and fixes that constitute the changes to be made to the organization in the future. Project Backlog items have, at a minimum, the attributes of a description, order, estimate, and value.

As a portfolio is delivered and the organization gains value, and the marketplace provides feedback, the Project Backlog becomes a larger and more exhaustive list. Project demands never stop changing, so a Project Backlog is a living artifact. Changes in business requirements, market conditions, or technology may cause changes in the Project Backlog.

Multiple Portfolio Teams often work together in the same organization. One Project Backlog is used to describe the upcoming work in the organization. A Project Backlog attribute that groups items may then be employed.

Project Backlog refinement is the act of adding detail, estimates, and order to items in the Project Backlog. This is an ongoing process in which the Product Owner and the PMO Team collaborate on the details of Project Backlog items. During Project Backlog refinement, items are reviewed and revised. The Portfolio Team decides how and when refinement is done. Refinement usually consumes 50% of the capacity of the Portfolio Owner and PMO Team. However, Project Backlog items can be updated at any time by the Product Owner or at the Product Owner’s discretion.

Higher ordered Project Backlog items are usually clearer and more detailed than lower ordered ones. More precise estimates are made based on the greater clarity and increased detail; the lower the order, the less detail. Project Backlog items that will occupy the Portfolio Team for the upcoming Portfolio Cycle are refined so that any one item can be decided on within the Portfolio Planning Meeting. Project Backlog items that can be decided on by the Portfolio Team within a Portfolio Planning Meeting are deemed “Ready” for selection in a Portfolio Planning. Project Backlog items usually acquire this degree of transparency through the above-described refining activities.

The Portfolio Owner and PMO Team is responsible for all estimates. The Product Owner may influence the PMO Team by helping it understand and select trade-offs, but the people who will perform the work make the final estimate.

6.2. Portfolio Backlog

The Portfolio Backlog is the set of Portfolio Backlog items selected for the Portfolio Cycle, plus a plan (i.e. resource allocation) for delivering the projects and realizing the Portfolio Goals. The Portfolio Backlog is a forecast by the Portfolio Team about what projects will be delivered by the organization.

The Portfolio Backlog makes visible all of the projects that the Portfolio Team identifies as necessary to meet the Portfolio Goals. An ideal way to represent the existing Portfolio Backlog is a Kanban board. For a portfolio managed with the APPMF as described in this guide, you could use the following columns:

1. More information needed
2. New (selected, but not yet started)
3. Validation (PoC and/or business case validation)
4. In progress
5. Done
6. Stopped

The Portfolio Backlog is a plan with enough detail that changes in progress can be understood in the Portfolio Planning and Review Meetings. The Portfolio Team modifies the Portfolio Backlog throughout the Portfolio Cycle, and the Portfolio Backlog emerges during the Portfolio Cycle. This emergence occurs as the Portfolio Team works through the plan and learns more about the projects needed to achieve the Portfolio Goal.

As new projects are required, the Portfolio Team adds it to the Portfolio Backlog. As work is performed or completed, the estimated remaining work is updated. When elements of the plan are deemed unnecessary, they are removed. Only the Portfolio Committee can change its Portfolio Backlog during a Portfolio Cycle. The Portfolio Backlog is a highly visible, real-time picture of the projects that the Portfolio Team plans to be delivered by the organization in order to reach its goals.

6.3. Portfolio Reports

Reporting is critical to an effective project portfolio management. Whereas collecting up-to-date and accurate data is a challenge, building an efficient reporting system is relatively easy. Reports should answer specific questions and be tied to specific processes. Reports that simply look appealing or provide a host of data without underlying meaning are ineffective.

At any point in time in a Portfolio Cycle, the total work remaining in the Portfolio Backlog can be summed. The Portfolio Owner, as well as the PMO Team, tracks this total work remaining at least for every Portfolio Review Meeting to project the likelihood of achieving the Portfolio Goals. By tracking the remaining work throughout the Portfolio Cycle, the Portfolio Team can manage its progress.

The minimal set of metrics that should be monitored for each project on the Portfolio Backlog are:

- Estimated end date (for resource allocation)
- Costs till date (exact number)
- Expected costs till finish (rough estimation)
- Remaining budget (exact number)
- Delivered value since last status update (YES/NO question)
- Expected gain on investment
- Risks
- Issues
- Allocated resources

For all projects that are delivered or partly delivered, you should track metrics like:

- Stakeholder satisfaction
- Customer satisfaction
- Quality delivered to customer
- Return on Investment
- Meeting business case objectives
- Customer adoption
- Meeting governance criteria
- Benefits realization

Only by tracking these for a period of time after project completion can you verify if they delivered what you have planned for in your portfolio. When converting these metrics in reports, it is important to consider the following key report types:

Single-page project report: Using a consistent format for project status reports is important. Doing so means less time can be spent on the layout and more attention can be paid to the data within the report. Each project summary should be contained on a single page or screen, with top-level details and the contact information for the project manager and project owner provided should questions arise. The data should also be time-stamped.

Financial information: This provides aggregate roll-up on budget and costs across projects with the ability to drill-down into individual projects.

Project dashboard: One-line summaries of the projects currently on the Portfolio Backlog, filterable by important grouping such as division or project sponsor (see Categorization). Often these lists can run to hundreds of projects, so by default, filter on the poorly performing projects (such as no value delivered on the status indicator) first, as it is likely those projects are of most interest and require the most attention.

Resource allocation view: This is a view of current resource availability and utilization for the coming 12 months. This means people, machines, money, and anything else that could be a bottleneck in realizing your projects.

Strategic alignment: This provides a view of the strategic goals of the business and how the current projects contribute to them.

Flexible pivot table capabilities: No project report or set of reports will capture everything that is needed, even where drill-down capabilities are available. Using a drag-and-drop pivot table-style analysis on the inventory of projects or proposals can help executives and others find the information that they need to answer a particular question and also lead to creative analysis to produce new report types to further support decision making.

6.4. Artifact Transparency

The APPMF relies on transparency. Decisions to optimize value and control risk are made based on the perceived state of the artifacts. To the extent that transparency is complete, these decisions have a sound basis. To the extent that the artifacts are incompletely transparent, these decisions can be flawed, value may diminish, and risk may increase.

The Portfolio Owner must work with the Product Committee, Portfolio Team, and other involved parties to understand if the artifacts are completely transparent. There are practices for coping with incomplete transparency; the Portfolio Owner must help everyone apply the most appropriate practices in the absence of complete transparency. A Portfolio Owner can detect incomplete transparency by inspecting the artifacts, sensing patterns, listening closely to what is being said, and detecting differences between expected and real results.

The Portfolio Owner’s job is to work with the Portfolio Team and the organization to increase the transparency of the artifacts. This work usually involves learning, convincing, and change. Transparency doesn’t occur overnight; it is a path.

7. End Note

The APPMF is free and offered in this Guide. APPMF’s roles, artifacts, events, and rules are mutable and implementing only parts of APPMF is possible. APPMF also functions well as a container for other techniques, methodologies, and practices. My advice would be to start implementing it as described in this guide and then inspect and adapt.

As experienced agile practitioners and as people responsible for agile change and transformation, we should recognize the importance of being agnostic with agility at any level. This means one size does not fit all, one framework is not the answer, and the 'what' and 'how' should be suited to client context and to a wider strategic vision.

We should take this very seriously. Our work is to help our clients and organizations attain the right level of agility that meets their needs; our work is not to create framework lock-ins nor to limit how agility can be applied to the organization, whether at team levels or at scale.

This means we as agile practitioners must strive to be masters of our craft, understand and practice at least two formally established frameworks or methods, uphold good conduct between ourselves and others, and help to nurture and grow our community of agile practitioners.