Vertical Slice

Most of the meaningful things I've done over my professional career have been accomplished via the execution of projects.

Executing a project well is difficult for a number of reasons, but one of the most pertinent is that decisions made early can have wide-ranging long-term ramifications.

The core reason why you're doing what you're doing and what you're hoping to get out the other side, aka the project framing, is just one example of an early decision that can have a big impact moving forward.

So you should probably put some effort into it.

We've Seen This Before

If you've ever done any software development using agile methodologies, you're probably familiar with the concept of a user story.

A user story is the smallest unit of work that can be completed by a delivery team, representing some process or piece of functionality that helps a user to achieve a goal.

On completion of a story, a user could, conceivably, use whatever it was that was delivered in order to make their lives easier. It might not be perfect, it definitely won't handle all of the edge cases and different variations of the situation, but it will work end-to-end.

In order to enable this delivery of value, a good story describes a problem to be solved and does not specify the solution, leaving that up to the implementor.

Of course, the delivery of a story will require the team who are actually building the thing to go into detail about how they are going to go about it, but focusing on the problem to be solved instead of how the problem should be solved gives an immense amount of flexibility for solving it effectively.

One of the best ways to frame a project is to treat it as a really big story.

That might sound like something of a gross simplification, but bear with me.

A Universe On The Brink of Annihilation

If you frame a project as a story, it makes it easier for stakeholders to understand.

If you've defined a project that is focused on a specific solution, or even worse, focused on a particular technical stepping stone, then people who are even slightly disconnected from your day to day are going to have difficulty understanding why they should care. The more specialised the knowledge required to comprehend, the less likely it is that people will actually take the time to gain that knowledge.

This gap becomes problematic when you need support, like getting other teams to prioritise dependent work or acquiring additional resources to actually work on the project in question.

The simpler you can make it for people to understand the value you are going to deliver, the better the outcomes are going to be. A great way to do that is to frame the entire thing as a story, clearly describing the problem and who will benefit from its solution.

But wait, there's more!

Framing a project as a story also gives a lot of flexibility in execution.

If you're aiming to solve a problem rather than implement a specific solution, you can try a bunch of different things and see which one is the most effective. You can pivot as necessary if the path you're already on isn't looking promising. You can go back to the drawing board and start again if you absolutely must.

That sort of flexibility is incredibly valuable in maximising the chances that something of value will actually be delivered.

Of course, you have to temper those sorts of things with the realities of the situation, because every misstep and backtrack comes with a cost, but because you're not committed to delivering something specific, you have the freedom to adjust and change as necessary.

Assuming the money holds out of course.

But This Particular Story

Treating projects as really big stories isn't perfect.

For one thing, it's hard to get people to not immediately think about solutions, which means the project management takes more effort because you have to keep reorienting people.

Most people default to solution mode when they are presented with a piece of work or a problem and whatever solution they come up with gets stuck in their mind. Forcing them to take a step back and focus on what needs to be achieved (instead of how) can take a lot of effort and ruffle a few feathers.

It's understandable though, because ideas and goals by themselves are somewhat worthless without a plan to actually achieve them. Don't discard any of that delicious solution detail or discourage people from thinking like that, just redirect it and separate the two concerns.

Shifting people away from the solution makes harder to estimate the project, which makes managing stakeholder expectations more difficult.

In order to estimate, you need to either have a yardstick (i.e. this thing is like this other thing so it's probably similar in size), or you need to understand the detail enough to be able to sum a bunch of disparate activities together and get a total.

This works nicely for traditional user stories, because they are small and thus easier to understand, and you often have many comparison points.

When treating a project like a really big story, the work is not often fully understood and it's rare to find other, similar projects to act as yardsticks.

That means that stakeholders either have to be comfortable with fuzzy estimates or you have to flip the script and instead set a deadline by which outcomes need to be achieved and manage scope and expectations within that timeframe.

It Breaks My Heart

I find that framing projects as stories keeps them focused on the value that they are meant to deliver to the business. In turn, that makes it easier to manage the project to a successful outcome.

That doesn't mean managing those projects is easy though, but project execution is not the sort of war that you can win with one authoritative strike. It's a war that you win through attrition, mounting up more individual victories than losses.

You do that by doing small things well, like framing and naming.