Several years ago, when I brought up the topic of project resource planning with the CIO of a large educational organization, we discussed improving their portfolio process. He began by telling me, tongue firmly in cheek, that they didn’t have a problem.
The top 20% of annual priorities got done, and 30% of the truly urgent operational work was done, which meant they were doing okay. I asked if anyone cared about the other 50%, which we agreed to call the “messy middle.” He just shrugged his shoulders.
In theory, this out-of-sight-out-of-mind attitude is one of the problems agile methodology for software development has claimed to solve by moving to products. Unfortunately, I think the shift has given rise to a new problem: the false dichotomy of “products, good; projects, bad.”
Finding the best fit
While “product-mode” initially referred to on-going work on a product—building, updating, debugging, implementing customer feedback, etc.—it’s proven immensely valuable for internal initiatives as well. Operational work, for example, is ongoing in nature. Internal problem solving and keep-the-lights-on activities fit nicely into product mode as opposed to project mode.
Multi-project resource planning is designed to deliver a unique, complicated, or complex outcome under conditions of uncertainty. Adopting a product resource planning perspective is a better way to deal with “move this, change this, add this” types of requests.
In theory, we can imagine a collaborative system where projects and products both have their place. But, as is often the case, problems start to arise once we reach the funding stage.
What people want may not be what the business needs
I once had a PMO ask for help because their agile product teams were asking for a bucket of money for the year, and the only oversight into how the money was being spent would come from the product owner. In a situation like this, I can see why the head of PMO was concerned.
But I also understand why the product team was pushing for this structure. In today’s world, every business unit has a right to continuous technical support, just like they have a right to have staff members dedicated to their function.
The goal of product teams is to maintain current and future operations, but that can be difficult to plan for from a budgetary standpoint. Often, agile product teams ask for large budgets without any tangible explanation for how those funds will be allocated — they claim it will be up to the team and the product owner. However, in my experience, what’s vitally important to each business unit may not be vitally important to the company as a whole.
A CIO once shared with me that he’d spent years being the most customer-centric CIO he could be. Everything in his shop was customized to meet the work practices of the current staff. But five years later, when a new crop of people joined the company, they kept coming to the CIO and asking, “Why does this work this way?” He finished his story by saying that he finally ripped everything out, replaced it with SaaS software, and told everyone that they could have any color they wanted so long as it was black[i].
Technology is just as important for the ongoing operational effectiveness of a business unit as its people are. ASD has already bridged much of this technology gap by focusing on products that serve a specific user population. This indirectly makes it possible to transfer both people and funding to the business unit itself.
People only need fixity under stress
In a flawed system, people tend to advocate for rules that optimize their own quality of life. People like the notion of fixed funding and fixed teams because it offers them stability and some control over their own lives. When we open each team up to being dynamically reconfigured to meet the needs of the business, that apparent control and stability disappear.
I believe this sense of control is the missing piece of the puzzle. It’s not an argument between products or projects; it’s an argument over how much control people have over their work and their time. And the solution is a combination of resource capacity planning, resource allocation, and skills management.
Projects and products are NOT an either-or proposition. Assuming anything is “fixed” is incompatible with the amount of change and disruption present in the world today. On the other hand, if we address the needs of people for job satisfaction and career growth, then people can move on and off product teams when an opportunity makes sense for both them and the business.
We need to make sure that funding and people match by using scrupulous resource capacity planning. We need to ensure we are always working on the right work at the right time by using strategic roadmaps to sequence work. Finally, we need to stop asking people to shift what they are working on three times a day by clarifying that “getting to done” is the goal.
In the final analysis, the right resource management software gives us all the tools we need to fix the problems we are struggling with. Introducing false dichotomies between projects and products muddies the water and makes life overly stressful for the people doing the work.
[i] A quote attributed to Henry Ford when asked if his cars came in colors.
