We want to use this article to bring light to a messy understanding of products, projects, and teams, the three big players in the portfolio management of corporate products. They represent the ideas, plans, and delivery units.
The Products
In this structure, the product is a representation of ideas coming from a group of people which has the goal to create or change business capacities in the organization. The common structure used to show these ideas is the story map, which is a visual representation that helps in the agility of high, middle, and low levels of decision making.
A product has no planned end, as a project must have because it has a constant flow of evolutions and corrections happening during its entire life cycle. A product may be turned off but it is not usually an expected goal. The use of modules, epics, stories makes the logic of its structure pretty clear and creates an efficient communication channel among the organization members.
As the weeks go by, new ideas and new capacities are added, growing the map and demanding a maintenance routine, keeping only what was already planned to be done and the most recent history. You can use electronic tools to create and keep the consolidations.
Working like an organized database of ideas and static ideas do not make money nor contribute to the community, the product needs other structures to plan and build concrete capacities from ideas. We use projects to plan the executions.
The Projects
The major reason behind this whole text, ugly duck in current portfolio management even inspiring a famous hashtag in Twitter, #NoProjects, becoming a book afterward. The misuse by the traditional managers created so huge trauma in the current managers they can’t even hear the word “project” anymore. The belief that the project was the bad guy here drove to some weird behaviors such as call it “initiatives”. We don’t do projects anymore, we do initiatives. Resemblances to “we don’t have teams anymore, we have squads” is not a coincidence and it happens over and over again because we are always trying to solve problems changing things names.
In practice, I’m not concerned about the name you are going to give to it if it will be a hot dog or a project, but you have to have an artifact to hold a plan on what we know at that very moment about deadlines and scope.
Reality and plans
The main motivator behind this bad feeling for the projects seems to be, as we look into this, the misusing of the artifact by the traditional management, just because they put aside the uncertainty and put a lot of faith and expectations in the plan when they should embrace the uncertainty, knowing the changing nature of the first plan. We should not adapt reality to the plan (a), but the plan to reality (b).
When the manager chooses the path (a) he creates an overload in the system because to put the reality into the plan he has to push. So, we start to see the common problems with this approach such as add new people to teams (Brooks), high pressure on lead time and throughput, lies, bloated estimates, so on. Every action that tries to put the reality into the plan boundaries is fragile. The reality will put you down.
To stick with the path (a) the manager first needs to know where his promises are going and what he can commit to. His decisions are based on reliable data and a strong belief in the uncertainty of the first ages of a plan, guide him by a strong and robust path. He knows that the first plan was expected to fail because the knowledge base is too poor, so he establishes review cadences to learn from the deliveries and adapt. If you trust in plans built on a high uncertainty environment, your management is fragile and inefficient.
If the pressure comes from the customer, we have a fragile agreement for the service provider, which is a symptom of bad knowledge about the premisses of the software development negotiations such as the flexibility of scope or deadline.
Due again to the uncertainty, now during the contract negotiations, the inflexible scope is far less common, even in traditional organizations because discoveries happen along with the deliveries, creating the need for change requests (CRs) throughout the development period (waterfall). Besides the high faith in its planners, the early plans always fail in software development processes and you must adapt. The changes mean that you are learning.
If you have an agreement not following the premises above, you have a win-loose contract and the service providers in this situation try to reduce the losses using bloated estimates, selling senior developers, and allocating juniors, for example. If they don’t do that, they are broke. Then both companies build layers and layers of management to deal with the problems wasting a lot of money on activities that are not product development.
Looking at this angle it is a lose-lose relationship.
Our cornerstone here is about the high level of uncertainty in the beginning and how normal it is because we only can walk on the cone of uncertainty with execution. The more pieces of code you put in production, the more will be the feedback you will receive, the more will be your knowledge about the product and its behavior. We have many variables here and we only know them when they play along in the same environment. The faster we start, the faster we will be comfortable with projections, estimates, and expectations.
So we have to start as sooner as possible and establish cadences of review, each one of them ready to provide the necessary information to learn and adapt faster enough to keep the relevance of our product in society.
The projects also can be part of a greater structure, so-called programs, and it would be a collection of projects seeking a greater goal for a product or a set of products (organization strategy). The program has inside a set of projects competing for resources and the project has inside demands competing for resources. It is a fractal portfolio.
We don’t have isolated needs In a professional environment. They are always competing for resources.
Project Size
We suggest projects between two and six months, but this decision is strictly related to the dynamics of the teams executing those projects. The right size is important because too small batches do not provide enough time to learn and adapt inside the same project and we avoid the big ones because we want to be able to make a fresh new plan and reset using what we’ve learned.
Starting projects should use data from other projects of the same product or team and if you don’t have them too, you should estimate. As far as you get from the product, the more uncertainty you will have. However, it is not an issue since we will set disciplined and cadenced reviews of the original plan.
This process leverages the learning, planning, control, and execution cycles which provides an environment where the knowledge of the product, of the system, and of the environment itself grows. If you don’t have this bigger batch of management you lock your learning of the system, especially on deadlines, therefore, on the predictability.
Let’s try a quick simulation.
Simulation:
We are on 03/23/2020 and at the end of the day, we would like to have the planning and the setup of the Voyager Project. After building the story map we can now pick up the most important needs for the short term and run the Monte Carlo simulation for that scope. The result was 06/30/2020 as a deadline with odds of 80%. Now we have a scope to start and an initial deadline.
The Voyager is the second project of the Product Apolo and, as we are a company that learns with previous data, we are aware of the chances of variation of 30% in the initial deadline planned. After this quick information gathering and planning we assembly a meeting to expose the information on how the management team expects the project to behave. All people involved should attend this meeting or send a representative. This is a common practice in the software development industry.
After a couple of weeks, the management team meets again and makes a new projection for the deadline using the new data and now the result shows 07/30/2020 as the most probable deadline, a month later. But is that a fixed date project? Is it attached to an important event or something? So the management starts to cut scope off using the people and tools they need to accomplish this important task. If the scope cut happened with no major problems, the cadence still the same, but if it increased the project’s risk the frequency of this review may have to be shortened.
In the next review, again having new data, the result is better and shows 05/15/2020 as a probable deadline and it will be safe to add more items, returning old or adding new ones.
Each change in the real world causes a change in the plans. This is the law. You have to make the right choice for each moment. Sometimes you will have to cut scope and sometimes you will have to push or to pull the deadline. The highlight here is the data-based decision making driving to better and more robust results.
The effectiveness of this meeting, generating useful results using very short meetings, allow the keeping of the right frequency to the amount of risk in the environment, that is, riskier projects meet more frequently.
The main point here is that if there isn’t an initial batch of planning we wouldn’t have a base to unfold new information and learning. A flexible deadline does not mean any deadline at all. Flexibility in scope does not mean any scope at all.
In a nutshell, projects are plans to put in movement the ideas for the product, helping to turn abstract ideas into a concrete product.
The Teams
Calling it “squads” or just teams, what we have here are the execution units of projects. If the project is the plan to put ideas into movement, the teams are who in fact, transform ideas into real products. They refine, execute, test, and feedback on the ideas.
There are some ways to organize the teams but it is not the focus of this article. We also have some approaches focusing on the organization and structure of the customers and services instead of teams, but it isn’t the focus here either.
The main goal here was to conclude that we have three main structures when we are organizing and managing software projects: product, project, and teams. The product is the structured database of ideas, the projects are the planning to execute these ideas and the team executes and the results of its work feedback the initial planning, evolving it.
This text was originally published in Brazilian Portuguese here.
