There was a time when business cases were weighed rather than read, and it routinely took six months for a fast-track proposal to get approved in the portfolio. Today, things may move a little faster and with less paperwork, but no one would label the process either fast or agile.
To increase agility, we need to develop a new mental model for our strategic portfolio management approach. A new investment or project should either be classified as strategic or operational. A proposed project either helps deliver a planned strategic outcome or is designed to primarily support operational objectives.
While it’s possible for a project to serve both purposes, defining every proposal by its primary focus saves time, effort, and energy. From this point, it’s possible to decide how much money the organization wants to spend on strategic projects and how much it wants to spend on operational projects.
Agility requires seeing the whole and the parts
Based on 10 years of speaking with companies all over the world, I’d guess that somewhere between 10% and 20% of companies have an effective portfolio process. So, what exactly are these companies doing that works?
In all cases, they have spent the time to determine what is truly important, then committed their resources to get it done quickly. These companies have learned that it’s the people assigned to do the work who determine both how fast the work gets done and when that works starts delivering the value the company was hoping to receive.
Notice the link between available resources and outcomes. Manufacturing proved decades ago that doing something until it’s done and then moving on to the next important activity is the most productive approach. This means approving and starting 100 projects in January when there are only resources to start a quarter of that number creates an initial condition of resource competition and a mindset that “interruptions or delays are good” because then it’s possible to move something else forward.
Most organizations segment out their highest priority projects because they know those projects won’t get done otherwise. But then, they leave the “messy middle.” The remaining projects get caught in an endless loop of interruptions and resource competition that agile was intended to fix and hasn’t.
How can applying a truly agile mindset to the beginning of the portfolio process solve this persistent and very expensive problem? By admitting that capacity is not only limited, but that it will always be limited.
The shared services model alone cannot solve the resource constraint problem
When IT and later segments of product development embraced the shared services model, it seemed to make sense. Rather than try to add specialized skills to each team, why not gather people with those skills and then prioritize where those skills could be put to the best use?
The secret to successfully using this model is that the organization needs a very clear method of prioritization that is rigorously adhered to. The organization also needs to be very clear about how many of these scarce resources will be required to do the work that has been released from the portfolio queue.
This means if you have a small team of 5 people with scarce skills, you can’t start projects that will require 7 people without getting more people. The model is incredibly easy to understand. Throughput is limited to the capacity of the bottleneck. Simply putting those five people in a shared service team does not remove the constraint, and it does NOT create more time.
Resource capacity and resource allocation need to drive the strategic portfolio process
While it’s hard to quantify, my guess is that somewhere between 80% and 90% of organizations have more money available for new work than they have people to do the work. This is not an oversight, and it’s not by accident.
Employees are a structural cost. Scaling employment up for a single year and then laying people off is not good PR and is upsetting to everyone in the company. In today’s economy, companies can scale using gig workers, but smart companies know that all this does is eliminate any potential competitive advantage they can get from their “digital initiatives.”
What’s the solution? Ration demand for improvements and changes to systems of record¹. From an agile perspective, look at the support of your systems of record as a single, large time box. For the year, you will authorize only so much investment in terms of people (both employees and gig workers).
The shared service center concept was originally intended to simply support systems of record. It was only when the concept was expanded beyond this function that organizations started getting into trouble.
Outlining all the steps needed to fund, manage, and update systems of records (and do it well) would take an entire white paper, so I’ll just list my top four suggestions:
- Retire outdated systems
- Train product managers (not system owners) to optimize the capabilities for the product rather than to just complete user requests
- Employ gig workers as necessary for work on systems of record. These skills are easy to come by, and it frees up internal resources to take on new “digital initiatives”
- Decide how much money the organization is willing to give to the area in advance and do not exceed the number without a very good reason
Once the issue of supporting systems of record and existing internal products has been taken care of, everything else can be broken down into 2 categories: variations on existing product/software, and new products/software to continue to support the company’s ongoing operational excellence and revenue (see figure 1)
Most organizations think in dollars when they are doing this analysis, but headcount is what matters. I’ve recently seen some suggested portfolio reports that show FTE headcount required on all the top-level investment reports. This is a huge step in the right direction. Top management can easily see where all the resources are going (or not going).
With the unfortunate advent of covid-19, organizations were finally able to see just how fast they could move when they had to. The smart organizations are going to remember this lesson and try to find a way to maintain the agility. The primary lesson everyone should have learned is that scattering resources and focusing on progress has been the wrong measure. We need to focus on RESULTS. Agility requires focus, and focus requires committing people to work on the most important initiatives until they are done.
¹Gartner Pace Layer divides IT systems into 3 groups. Systems of record (HR, Finance, Supply chain). Systems of differentiation (unique customizations that give a company a competitive advantage) and Systems of Innovation.
