The Alignment Model

A short while ago the extremely excellent Frank Ray scribbled a diagram on the back of a napkin (yes really) to explain his current project to a friend. The end result reminded him of a slide he had in a pitch deck from well over a decade ago … That slide was explaining how ideas moved from being an idea to becoming a solution.

It was a straightforward explanation of how stuff happens that had three sections: proposition, business requirements, and the solution.

Simple.

Except we know that getting stuff done is not actually simple in practice.

But as we talked through (and around) the slide and the scribbled map of his project, I realised that he was really onto something. The simplicity of the model highlighted some fundamental truths that more complex project models hide.

Some things matter more than others. And it’s not necessarily the bits you think.

This article is to take Frank’s model, explain and elaborate on it, and use it as a mechanism to discuss some of the things that I think matter about projects.

Buckle in, it’s a long one.

Disclaimer: What I’m talking about in this article is sort of my version of a pragmatic good practice. Not the best practice since best practice would be to follow genuinely some project management methodology or to do away with projects altogether!

So if you’re working in a beautiful project-managed world where there is a ton of structure, or if you’re in a wonderful product world where they’re focusing on value and outcomes – congrats! And also please note that this article will be unhelpful to you!

The model is basically as simple as Frank’s original (though of course I messed with the naming as I am wont to do). Let’s run through the parts. There are only three, so it won’t take long.

First up is the Proposition. This is where the project objective is agreed upon and outcomes are defined. The proposition can be defined in a big complex business case, a canvas, or something even less formal. The proposition is your project why. It explains the change expected from the project and the benefits of doing it.

Secondly, we have Alignment. Alignment is where the organisation works out what the change means and how to go about it – how they will operationalise it. What are the impacts to people, process, and tools? Where are the constraints? How will it work in practice? Alignment is where how is worked out. This is messy. There are people, processes, funding, and all the existing organisational baggage to contend with in this box.

And last we have Execution. This is exactly what it says on the can! This is the actual build or implementation of the solution. This is specs and data and code and process changes. Execution is the what! And the fun part (if you’re like me!)

And let’s pull it all together into one simple picture:

This is the point when you realise that I’ve essentially just repackaged Simon Sinek’s Start with Why golden circle and applied it to projects. No shame, I absolutely have!

And I am not sorry at all because it is such a good model! And because you are likely already familiar with Simon’s model, the cognitive load of introducing yet another model into your brain is lessened. I call that a win-win.

Now, if you’ve had any serious involvement with the internals of organisations you’ll think: “Oof, alignment is doing a lot of heavy lifting in this model.”

You are not wrong.

Because if alignment covers everything between the business case to the implementation then there’s EVERYTHING in here. In simple environments alignment might be a breeze, in complex environments it takes skills and nous to navigate. Maybe you are realising that you spend more time sorting out alignment than you do in execution (as is true for me).

For a tiny organisation making a small change, alignment might be as simple as a series of meetings to work out how to actually do the thing before simply doing the thing. Job done.

But for big programmes in a large enterprise, alignment might include everything from procurement (which is a whole thing in its own right), workforce and operations planning, architecture (both business and technical), solution scoping and requirements definition, customer research, market research, programme planning, funding, and, last but not least, people and all the politics and preferences that come along with them.

Alignment is all the messy things you find between an idea and its realisation. In complex environments, there’s a lot of stuff you need to align before you start building or implementing changes. And there’s actually no one-right-way to do this. The MVA (minimum viable alignment) depends on the complexity of the environment and you should pick a path that fits the context.

No matter what path you choose to follow to gather the necessary alignment, I cannot overstate the importance of doing this and doing it well. What happens in this stage has an oversized impact on the end result of the project and is where the real heavy lifting is. 🏋️‍♀️

But let’s get back to the model …

Simon is right. You should always start with why.

Ideas move from proposition through alignment and out into execution. That’s what they arrow is all about!

But before you get all hot and bothered that I’ve just drawn a hierarchical waterfall project diagram, I want to make a couple of things clear.

The arrow is directional

The arrow is directional rather than sequential or linear. In fact all the best learnings from the model come from applying it in an iterative context.

Waterfall attempts to remove risk by trying to do ALL parts of a stage before the next. Working through the model using a waterfall approach would look approximately like the version with the big simple arrow above.

On the other hand, iterative approaches attempt to remove risk by doing the hard stuff first and using the learning to de-risk subsequent stuff. Or at least it should (she says while attempting to avoid any real discussion about agile because it’s not the purpose of this article).

To take a non-linear approach, you want to be doing just enough alignment to build the next thing. Working through the model using an iterative approach would look like this:

And arguably, just enough alignment should be the approach no matter how small (or large) your delivery chunks are. You want to bake – but not over-bake – the cake.

But no matter what flavour of delivery you’ve selected, the drive is always towards the solution. And in doing so we build momentum.

Change is action. It is movement. And in a project setting, we can become single-minded about the goal. We deliberately build momentum.

Momentum is great, it helps us maintain focus, it ensures the org around us is aware of our work and keeps us in mind. It helps maintain orientation. But if you’re all facing the same way, it’s easier to miss when a problem isn’t as small as it seems. And not all problems are created equal.

Using the model we can identify three different types of problems. Trust me: these distinctions are helpful.

The a-ha moment I had when Frank was showing me his napkin scribble was that in the simplicity of the model, all the really important stuff was highlighted!

Without a good proposition, alignment is challenging if not impossible. Without good alignment, the solution is compromised. It might feel like we’re reducing the complexity to an A-B-C (or P-A-S?), but in doing so we’ve limited noise from all the distracting details to focus solely on the bits that always matter.

This is the entire point of a model: to eliminate unnecessary detail so you can focus on what’s important.

Time and time again we get sooooo hung up on process and details (these types of requirements, and this particular format for documentation) and spend far too little time focusing on the shit that really matters.

You’ll notice that I didn’t once mention outputs in this entire 2000+ word essay. I didn’t, because it isn’t as important as understanding the whole.

So here’s the million dollar question: Is what you’re working on moving you closer to the goal?