Planning projects in a product world
Projects were at the heart of software development in the good old days. We sold a bunch of features against a tight deadline for a fixed price. All we needed was a five-star general to ensure the troops stormed the beach according to plan.
With the adoption of agile software development, the Project paradigm has been replaced, and we're all building Products now. We've replaced Project Managers with Scrum Masters, Product Owners, and coaches. Even the acronym PM refers to Product Manager these days.
Where in the old days, everything was a project, we now treat everything as if it were a product. But is that really the case?
What's the difference again?
Projects
They are designed to achieve a specific outcome.
They have fixed scope, budget, and timing. While there's often room to go over budget, a project is successful if the outcome is attained without breaking the Iron Triangle.
A project plan is rigid. We only change the plan if unexpected events force our hand. Change is bad.
Project teams are short-lived and designed for the sole purpose of getting to that outcome.
Half a project is worthless. It's all or nothing.
Projects will be Done, they have a due date.
Products
They are designed to serve a specific customer.
They have an almost indefinite timeframe. As long as the product is developed, there is a budget. Rather than scope, there's a set of experiments driven by customer feedback.
Product plans are highly volatile. They change whenever we catch new feedback. Change is good.
Product teams are long-lived and designed to study and serve the customer.
Each product increment adds value
Products are never Done.
Over the years, we've learned that a product-style approach is a natural fit for software development's rock 'n roll. The feedback-driven flow works better for creative discovery than strict Work Breakdown Structures.
Yet, not everything is a product. Sometimes, we want to achieve a specific outcome. We know exactly what we want; we just need to find the time.
Project work
Sometimes we have a big chunk of predictable work that's all-or-nothing. For example, let's say we want to upgrade all our microservices to the latest version of NodeJs before they reach End-of-Life. While there might be some technical uncertainty, there will be no new customer feedback or insights. Half an upgrade isn't valuable and there's a due date. It's clearly project work.
If that work can be done by outsiders, the answer is straightforward. We assemble a separate project team, define the scope and go to work—old school style.
But often, we need projects within product teams. Let's assume these NodeJs upgrades can only be done by members of a product team. How do we handle that?
We could set aside three weeks of focus time to solve this problem, but that means no user feedback for over a month. It also relies heavily on estimates: we just hope we get everything done in three weeks. Moreover, these project tasks are usually not something the entire team can work on. The front-end developers typically stay clear of these NodeJs upgrades. It's not focus unless the whole team focuses.
Usually we will break up this project's scope into multiple tasks and add these to the Product Backlog. We treat these as regular product work. And that's where the trouble starts.
Since these individual tasks don't deliver direct customer value, they are bound to get deprioritized. Product Management is all about capturing feedback early. Tickets that don't help gather feedback tend to slip to the bottom of the priority queue. The project that's only valuable when completed never gets truly done.
"Will these changes be ready before we reach EOL?". Who knows?
Project bandwidth
One of the cleanest ways of handling these mini-projects is to allocate a fixed portion of our team's capacity to the project. We could assign one or more fixed "Project Days" in the work week. Every Friday, 2 of the team's backend developers will be committed to the NodeJs upgrade project.
This has several advantages:
We can plan the work. We know exactly how much bandwidth we can allocate. After the first upgraded microservice, we'll have a pretty good idea of when we will be ready. All the classic PM tools are available.
We can assign a dedicated short-lived project team. We can pool talents and share knowledge if multiple teams need to upgrade their Node version.
We don't block feedback. While developing these projects, we're still working on our product. This approach will reduce our capacity, but we're never too busy to capture customer feedback.
Allocating bandwidth is especially valuable when tackling cross-team initiatives. The cost in capacity is visible, and reporting to stakeholders is straightforward. In organizations with many of these top-down initiatives, it also helps spread the workload: one project per team at a time.
This might feel awkward for teams that have gone all-in on the product paradigm. It might feel like going back to the old ways. It's not. It's a matter of using the right tools for the job. Project work requires a project approach. The alternative is treating these initiatives as product work and just hoping they'll get done one day.