The route to portfolio speed with the lowest possible need for transformation
As a professional working in a large organization, you will, unfortunately, recognize these situations (or versions of them):
Situation 1: Org not getting what they want on time
Sales are waiting for a critical update to their software package to work with their customers in a data-driven way. Some other part of the organization is responsible for the update (probably IT). Unfortunately, the update is not on time, and when it shows up, it does not move the needle for the sales teams using it. It also turns out the deliverables were different from the right deliverables.
Situation 2: missing market opportunities
Marketing has identified a gap in the market. We have a significant opportunity if we can develop a version of our product that can fill it. A project to develop the product is started, but when we finally launch, it is too late, and we become one of many in the market that fill the gap. We needed to move faster to profit from our data-driven marketing efforts.
All of the situations mentioned here are common in many organizations. The situations can be seen as symptoms that something inside the machinery of an organization is not quite working right. Signs that lead to effective transformation programs. Lean transformation. Agile transformation. Scrum, SAFE, the Spotify setup, etc. The problem with majorly transforming an enterprise with an extensive program is that it takes a lot of energy and force. And there is no guarantee that the symptoms we saw go away just because we now adhere to the latest agile framework (or some not-so-agile frameworks, for that matter). The transformation projects themselves suffer from similar symptoms as the three examples, with "death star"-projects that fail to achieve the required result and timelines that never end.
Fix small broken parts instead of doing a major renovation
What could be done instead of effective transformation programs? Start positive change by making a few better choices. Small behavioral changes. So what are some of the simple things we can consider?
There are two essential resources/ insights I like to use when I think about transformation through small actions:
Little's law
The VUT equation
Why these two? Because they are generic and fit all situations! (almost) You don't need to get certified coaches, you don't need to use new canvases, and you don't need to build new software. Just to let you know, an explanation of the two is in order.
Little's law
https://en.wikipedia.org/wiki/Little's_law
Little's law is a core principle found in queueing theory. Don't let that complicated origin scare you off. The fact is that knowledge of, and application of, Little's law is one of the easiest ways you can increase speed in your organization. In simple language, Little's law tells us that the time an object spends in a system (a project in a portfolio, a product we are manufacturing in the factory, a ticket in a ticketing system) will be directly proportional to how many objects there are in the system.
Let's say we have a project organization executing a portfolio of projects. In general, the time from start to finish of these projects will decrease if the organization decreases the number of projects that are worked on in parallel. For example, let's say that we go from working on ten projects to working on five projects instead. The time from start to finish will go down by 50%. There are caveats to this claim. For instance, there can't be significant external dependencies that cause slow delivery if Little's law is to work, etc. Little's law is straightforward to apply if the projects have relatively low touch time, i.e., a short time when someone is working on them, and long queue times, i.e., when they are standing still waiting for something. Knowing that multi-tasking or parallel execution is a major cause of slow delivery is a crucial insight. And it is easy to avoid! Simply stop starting projects, and start finishing projects. Make sure to track the number of finished projects. Make it a critical KPI.
If we go back to our examples, our sales department getting the wrong thing late, and our organization simultaneously missing a market window, are both in high likelihood connected to too many projects/priorities/activities at the same time. Most organizations could decrease the content of their project portfolio by at least 30% without incurring any significant challenges to how they operate. The mantra should be "The organization can have whatever it wants, but not all at the same time."
The value of avoiding multitasking can be easily understood through a simple example. Imagine we have a project portfolio consisting of 9 projects. Let us look at two cases. One where we choose to work on three projects in parallel, finishing them and then starting with three more. Then we compare that to a case where we start all nine projects simultaneously.
Since, in this example, we are working at a constant rate, we can see how value gets created over time from our projects.
At the end of the day, we delivered nine projects, so the reduction did not have any impact, right? Wrong! Assuming that the value from what we deliver continues over time, the total value will actually double.
Double. From doing the same things, except just not all at the same time.
The VUT equation
https://en.wikipedia.org/wiki/Kingman's_formula
The VUT equation is another golden nugget from queuing theory. Whereas Little's law tells us about the system in all situations, the VUT equation tells us about the system's behavior when there is variability. VUT stands for V= Variability, U= utilization, and T= service time. The VUT equation is also known as Kingsman's formula.
With an understanding of the VUT equation, we understand how queues inside our system start to behave when we load our people (or resources). How busy are they? When we have variability, the time, for instance, a project will stay in the queue, will go up when the resource is busier. It makes sense when you think about it. A busy resource will take longer to answer any unforeseen events. This effect will be exponential once the utilization reaches high numbers, even if the variability is relatively low. What does this mean? It means that the tendency of always loading people with at much work as possible gives us a mirage of productivity. While everyone is busy, our projects move through our organization slowly. One way of reducing the impact of the VUT equation is to have several resources available in parallel. This is an excellent idea in theory, but a project organization or a process often depends on one or two unique and expensive resources. This can be experts; it can be a costly machine or similar. Therefore, we must think long and hard about maximizing the system flow with variability in our system.
How to start applying our newfound knowledge
Track the number of projects you finish over in a given period. For instance, measure how many projects you have finished each year in the last five years. If your organization has not grown, the number of tasks completed will likely be relatively constant each year. You will then have a grasp of your project throughput. Then you can list the projects in your portfolio. How many are there? When you know how many projects you have in your portfolio and how many projects you finish in a year, you can calculate the average time to finish a project in your organization. Is that time longer than you are comfortable with? Then it is time to "finish 2, start 1" until you have a portfolio that allows the project times you are comfortable with. You can likely decrease inventory by 30% without any adverse effects at all.
Measure the load on your people. Limit the number of projects that people are engaged in. A suggestion is that a maximum of two tasks should be allotted to anyone. This will give visibility to where the constraints for your flow are in concise order and give you a way to increase your REAL productivity.
Being informed by Little's law and the VUT equation is one of the easiest ways to gain business agility. Give it a try!
