How Business Cases as Experiments Change the Project Portfolio Decisions

How Business Cases as Experiments Change the Project Portfolio Decisions

My clients all have too much work to do. So they ask the product or project leaders to write a business case for each effort. The clients claim this information helps them decide which work to do and not do.

However, everyone knows each business case is at least partially fiction. That's because the writer is supposed to include the estimates of time, cost, and ROI (return on investment). At the start of the project, when everyone knows the least.

I only wrote those business cases for the first couple of years I managed projects. Then I stopped because it was a waste of time. (I know, you are not me and we are both happy about that.)

However, if you reframe business cases as experiments, and describe what you want to learn, the portfolio team can make better decisions, faster and easier.

First, let's talk about who will collaborate on the content of these different kinds of business cases.

Who Decides on the Experiments

Because experiments manage risk, we need people with these perspectives to create the experiments:

• A product leader: someone who can see where the company wants to head with this product.
• A project “leader”: someone who takes the team's current cycle time and understands the risks for this potential work. This might not be a single person—it might be the entire team.
• Depending on the product, an architectural leader: someone who has been thinking about the various design tradeoffs for the entire product. Again, I prefer this is the entire team, but you might need a single person.

A collaborative team creates these experiments. Not one single person. (If you don't have access to a team, don't start this work. Wait until you have other people available.)

Even if your product is in its infancy, use a collaborative team to decide on these experiments. Create a team of three people and not more than seven. (Why seven? Because more than seven people is a committee and we all know how poorly committees work.)

Issues to Discuss for the Experiments

Here's what I like to discuss:

• Who is this product (or set of features) for? Which customers or users? (Those two terms are not always the same.)
• What outcomes do those people need? The outcomes are the problems we want to investigate and possibly solve for the customers or users.
• How long does each experiment need to run, to learn from the experiment? An experiment that requires three days is quite different than one that requires a month months. We might need a month, based on our cycle time, to create an MVE or MVP that allows us to run an experiment.
• What funding do we need for this batch of experiments?

Notice this has nothing to do with predictions of time, cost, or ROI.

We might want to collect some experiments together because they make sense together. Or because our portfolio team wants to fund us for a quarter at a time. However, if you have shorter feedback loops, you might want to separate those experiments into smaller chunks.

But thinking in experiments has another value to everyone. Because we need to limit our experiments, we start to move from how-much thinking to how-little thinking. We do that by thinking about problems, not feature sets. We don't have to break apart all those honking large feature sets to stories prematurely. Instead, we think about what we want to learn when.

Experiments Create Shorter Feedback Loops

Remember, the shorter your feedback loops, the more decision points you can create. Those decision points create more flexibility in the portfolio and often prune the product tree.

Since I'm assuming everyone on the team(s) work on just one team at a time, the funding question is mostly salary. Some products might require operating or capital expenditures, too. However, the more you frame the work as an experiment, the more likely you are to prevent early commitment to a tool or another product too early.

Results of Experiments

Remember, I'm the person who says, “Let's learn early, not fail fast.” The point of an experiment is to learn early. Regardless of the product results for that experiment.

If we learn early, we will learn about our customers and users—and which problems those people want us to solve. Even better, we will learn when the customers and users differ on which problems to solve when. (If you've ever sold a product to a vendor who bundled/resold that product to their customers, you might have seen this problem.)

With these experiments, we can choose what to put in which kind of a roadmap. We don't “commit” way too early to too many large feature sets. And we can see our cycle time before we commit to too much work. We might even see what we need to do to reduce our cycle time. This is an ideal time to tell the portfolio team we need to transform our project.

Experiments help us make better portfolio decisions.

Link the Experiments Results to the Project Portfolio Decisions

When we already have a pretty good idea of what to do for a product, we can use demos to show our progress. Does that mean the portfolio team should watch the demos? Yes!!!

Would they rather read something? I'm sure. But how can they see the value without watching the demos?

But when you're at the start of a project or a new release, and you're not sure where the value will be, seeing the results of experiments works too.

Why all this “seeing” business? Because a report does not convey the same information as a demo of some sort does.

When the portfolio team sees the results or progress, they can make better strategic decisions about this product compared to all the others.

Rethink Your Business Cases

If you think you need to write a business case, ask yourself these questions:

• Who does this business case serve?
• What data does that person/those people need?
• Can you reframe the case as a short series of experiments to help them make better decisions?

Now, you can decide what makes sense for you. If I was not so contrarian, I might suggest you write a business case with all the traditional unknowable nonsense first, and then write, “Here's an alternative case. What do you think of this?” and see what happens.

I'm more likely to skip the traditional and go directly to the experiment, but that's me.

If you're already using experiments for your business cases, please let me know if I forgot something. Thanks.