Digital Products Governance : The Porftolio Structure

In this article, we intend to undo the confusion between products, projects, and teams, the three significant pieces of digital product portfolio management. These pieces represent the ideas, plans, and units that execute the process. 

The products

In this context, the product represents the ideas of a group whose objective is to create or change one or more business capabilities of the organization. The story map is the most common format for displaying these ideas, a visual representation that helps speed up low, medium, and high-level decision-making.

<br>

A Story Map

A product, unlike a project, does not have a programmed end, as evolutions and corrections keep happening throughout its life cycle. Of course, the manager can turn it off, but usually, this is not a desired and planned objective. Instead, it has an evident structure, usually composed of modules, epics, and stories that create a base, also serving as an efficient communication channel between the organization's people.

Over time, as new ideas emerge and new capabilities are added, this map will grow, and a cadence will be necessary to clean it, only keeping what is planned to be done and the most recent history. Electronic tools can make and maintain consolidations.

As it is an organized bank of ideas, and a stopped idea does not generate profit or contribute to society, the products need some artifacts that help transform ideas into concrete capabilities. We use the projects to plan this execution.

The Projects

This article's primary focus and the ugly duckling of most agile people to the point of inspiring the hashtag "#NoProjects" also gave rise to a book. The misuse of projects by traditional management has created a real trauma in most current managers to the point that some people can no longer hear the word "project" and make some nicknames, such as "initiatives."

Despite this inappropriate use, initiatives have a more appropriate meaning in some companies that use them as grouping projects, usually with a larger objective, similar to PMI programs. These companies use programs to map and plan a continuous, long-term flow of activities while using short- and medium-term initiatives within a specific time frame. We don't see any problems with this type of use.

In practice, I don't care if you call it a hamburger or a project. The important thing is that we have some idea about what we know, at that very moment, about scope and deadlines.

Realities and Plans

The fundamental motivator of this feeling in the projects seems to be, as we found out, in the misuse of these artifacts by traditional management, when they dealt with both scope and deadline rigidly, plastering projections that should adapt to what happens in the real world. We must adapt plans to reality (a) and not reality to plan (b).

Clear examples of (b) are overtime, adding people to the team (Brooks), pressure on lead time and throughput, lies, "fat" in estimates, etc. All the measures, which try to fit reality into the "small box" of the plan conceived months ago, are fragile, and all have severe and, in many cases, even deadly consequences for the organization.

The examples of (a) are more straightforward: change in the deadline and/or vary in scope. It's no use crying. Your initial plan was wrong, and it was meant to be incorrect. Suppose you compromise the health of your organization, faithfully believing in the realization of projections developed in an environment of high uncertainty. In that case, your management is fragile and inefficient—both high and middle management.

If the pressure comes from the client, we have an agreement that was fragilely sewn for the service provider, indicating the lack of knowledge of some premises during the negotiation. Projects with a fixed date need the scope to be of high level and flexible; or on fixed-scope projects, the date will need to be flexible.

Again, due to the high level of uncertainty at the beginning, the second case: fixed-scope and flexible dates, are the least common, even in more traditional companies. 

Discoveries happen in the process, even if the dominant belief is that the company has excellent and experienced planners. The scope grows, and change will happen. So we have to expect change requests. 

Agreements that do not follow this premise are win-lose agreements, and to minimize this impact, suppliers use tricks, such as fat on deadlines and inexperienced professionals acting as if they were experienced, are examples. But, of course, if they don't, they break.

The consequence of this type of attitude is an expensive and wasteful contract. And supplier management spends most of their effort trying to close the equation, creating not one but several snowballs rolling downhill.

Looking at it from that angle, we have lose-lose agreements here.

Our basic premise is that at the beginning of the process, the level of uncertainty is high, and it should be that way because a system only walks in the cone of uncertainty with execution. The more we execute a project and the more projects we make of a given product, the more knowledge we will have of that product and the entire ecosystem.

Over time, we will know more about how it behaves in its final environment and how the current structure (teams and infrastructure) works together in this product. As the weeks pass, managing dependencies and customer expectations become easier.

As we have seen, these projects can also be part of a structure. Programs would be a set of projects that aim at a more significant objective, which can be the product or a group of products (organizational strategy).

Every program has projects within it that are competing for resources. So too, every project has demands within it that are competing for resources.

In a professional environment, you will hardly have an "isolated" demand, which does not have or generate dependencies and competitors. In this way, good management is concerned with a high-level view of planning and control and not just with short-term (immediate) management or individual demands.

Project Size

We suggest that projects are between 2 and 6 months in size, and the size decision depends on how the dynamics of the teams that will execute these projects work. We don't use small projects because we want it to be possible to learn and make planning adjustments within the same artifact, test management hypotheses, and kaizens. We don't use giant projects because we want the ability to re-plan and reconfigure based on what we've learned from the past.

Projects that are starting use data from other projects of the same product or team, and if this data does not exist, we use an initial estimate. The further we are from executions within the product scope, the more uncertainty we have. But that is not a problem because we will have revisions, cadenced and disciplined, to adjust the original plan.

This process enhances learning, planning, control, and execution that leads the organization to a state of the natural maturation of knowledge about the product. But on the other hand, not having larger batches of planning hinders learning about the system, especially regarding dates and predictability.

Let's do a quick simulation.

Simulation:

It's 03/23/2020, and the result of the day will be the planning and configuration of Project Voyager. When making the product story map, highlighting the most important scope for the short term, we ran the Monte Carlo simulation that suggested the date of 06/30/2020 with 80% confidence. So now we have the scope to start and an initial target date.

Voyager is the second Apollo Product project, and as we are in a learning organization, we know that in this product, the date variance can be up to 30% from the initial planning. These data are consolidated and informed to all those involved in the project, whether external or internal, in an initial meeting called Project Kick-off. Many in the market already know this practice.

After 15 days, the management team meets and makes a new projection, now with new data, about the end of the project, and the simulations now point to 07/30/2020, a month later.

But is this project a fixed date? Then management begins to cut the scope using the people and tools necessary to complete this critical task. If the scope cut has gone smoothly, the review cadence remains the same, but if the amount has increased the project risk, the frequency should be increased, with a shorter interval between meetings.

In the next revision, the simulation results in 05/15/2020, allowing more items to enter the scope.

Every change in the real world results in changes in the plan. It would be best if you made choices for each moment. Sometimes you will have to cut scope. Other times, push or pull the deadline. The data-driven decision-making process generates better results for the company.

The effectiveness of this meeting, generating relevant information using little time, allows it to be carried out with a frequency compatible with the project's risk profile. That is, riskier projects need more frequent reviews than simple projects.

The main point here is that without that initial planning batch, we wouldn't have a basis for deriving new information and learning. The flexible term does not mean zero terms, just as flexible scope does not mean zero scopes.

In this framework, we conclude that projects are plans to put product ideas in motion, helping transform the abstract into the concrete.

The Teams

Whether "squads" or just "teams," these are the units responsible for project execution. As projects move ideas forward, teams refine, execute, test, and provide feedback on the new ideas generated by their work. There are a few ways to organize teams, but it's not the focus of this article.

Our goal is to demonstrate that organizing and managing a software project portfolio can be divided into three verticals: product, project, and team. The product is the structure of ideas, the project is the planning of these ideas, and the team executes. The results of their work help to feed back the planning and the pool of ideas.

What do you think about better understanding how this structure fits into the 21st Century Corporate Product Governance?