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 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 knew he was saying this with his tongue firmly in his cheek, so I asked if anyone cared about the other 50% of the change budget, which we agreed to call the “messy middle.” He just shrugged his shoulders.
In theory, this is one of the problems Agile Software Development (ASD) has claimed to solve by moving to products. Since I have been recommending that IT move to products for operational work for two decades, I have no problem with this shift. The problem lies in the false dichotomy of “products, good; projects, bad.”
Funding products versus projects
I can understand why people want to see the backside of hundreds of small projects with their accompanying paperwork. However, while it allowed management to understand what work was requested, it proved disastrous as an execution methodology.
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.
The true difference between products and projects comes down to funding in the IT world. I was speaking with a PMO head the other day who asked for help because their ASD 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, the PMO head had a right to be 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.
Harness both multi-project resource planning and product resource planning to identify the high priority investments
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.
With the goal of providing an appropriate level of technology to the business units in mind, the next question most people ask is how much money any business unit should get to “maintain their current and near-future operations.” The answer I’ve heard from the ASD community has been, “give us money, and we’ll decide with our product owner how it should be spent.”
My response is equally simple. “No.” Having spent a significant portion of my career in finance, I can attest that what’s vitally important to each business unit may not be vitally important to the company as a whole. Despite all evidence to the contrary, no business unit or function ever has a guarantee of funding.
And now we’ve come full circle: we all agree that products make more sense than lots of small projects. But how should a product team justify what they’re working on? And how can management ensure they are funding the highest priority investment?
With real products, management can decide by looking at how much revenue a product brings in and at what margin. However, the decision is much more difficult with internal products and is often heavily influenced by politics.
What people want may not be what the business needs
A CIO I spoke with at a workshop once shared that he’d spent years being the most customer-centric CIO he could be. This meant that 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, the CIO realized that the new staff kept coming to him 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].
Obviously, there is still a need for what Gartner calls systems of differentiation[ii], which will require custom code as a bolt-on to a SaaS system. Still, these few cases will be much easier to evaluate because a system of differentiation, by definition, always offers a measurable competitive advantage.
Why the funding system and the headcount still get out of whack
In most organizations I’ve worked with, the budgeting process has a hole, and the truth is that the amount of money authorized rarely includes permission to hire the people required to do the work. Scrupulous resource capacity planning [iii](RCP) should enable companies to avoid this issue; however, I’ve seen organizations without strong RCP practices approve spending plans that exceeded their delivery capacity by 45%.
While I recognize how this mismatch between people and planned work could have happened in the past, I’m amazed that it still occurs, given the RCP technology available today. Organizations can’t afford to look at technology as an extra expense anymore. Digital transformation is table stakes for playing the game of business today.
So, does this mean I support giving a development team a bucket of money and letting them spend it any way they (and their product owner) thinks is appropriate? My answer has two parts: Yes to a fixed budget, and No to their ability to apply the spending to anything they want.
The power of a people capability development system
In a flawed system, people often advocate for rules that optimize their quality of life. One of the reasons people like the notion of fixed funding and fixed teams is 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 there is a middle ground between constant change and stasis: planned change. Imagine a system where an individual has active input into their career, where work assignments are flexible based on the individual’s and the company’s needs.
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 RCP, resource allocation, and people capability development, which luckily all come together in a single system like Tempus Resources.
Retaining and growing your employees
At the start of this blog, I mentioned that organizations routinely plan to do more work than the staff can complete. It’s my contention that the political benefits of this system at the executive level are completely offset by the burnout that employees have been reporting.
By harnessing both multi-project resource planning and product resource planning to ensure that headcount and planned work match from the beginning and using product roadmaps[iv] to ensure that all the projects are correctly sequenced for successful completion, employees might once again find an increased level of change tolerance.
Once the ground has stabilized under everyone’s feet, giving employees control over their future career direction would be the next logical step. Today’s resource management systems include RCP, resource allocation, and resource assignment features; they also include people capability development features that can be placed under the employee’s control. Having a skills and capabilities system behind the HR firewall doesn’t help employees plan their current career (what new skills to develop.) It also doesn’t allow employees to identify opportunities to do something else.
Traditionally, we’ve made employees quit and go to another company to gain this growth. I would contend it’s unnecessary, especially in a large company. If you let people bid on working on new and exciting “projects” and support them as they develop their unique skills, everyone might be a lot happier.
People only need fixity under stress
I started this blog by saying that projects and products are NOT an either-or proposition. I also contended that assuming anything is “fixed” is incompatible with the amount of change and disruption present in the world today. 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 RCP. 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, we have 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.