The Alignment Model

Or, the things that really matter ...

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.


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!

Introduction to the model

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:

A diagram with 3 concentric circles. The innermost circle is titled 'proposition', the
middle circle is titled 'alignment', and the outermost circle is titled 'execution'.
There is a circle showing direction from the innermost circle to the outer circle.
Proposition is annotated with 'why do this?', alignment is annotated with 'how do we do this?'
and execution is annoated with 'what are we building'.

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.

A short intermission about alignment

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 …

Start with why!

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.

A proposition doesn't have to come from the top

While I imagine you assume that I’m only applying this to big directives from the exec, I actually think that the model works for delegated structures just as well! There is always a proposition, there’s always some level of alignment, and there’s always some amount of execution.

While I’m sure smart product people will have a ton of contrary opinions (and you should totally listen to them over my humble ramblings), for product-led organisations, there’s no reason why the proposition couldn’t be a hypothesis!

It doesn’t matter if you’re building a spaceship, a new widget, or running an experiment, the bits (proposition, alignment, execution) remain consistent. And they remain consistent no matter who makes the proposition, whether a team, a product manager, a head-of, or the CEO.

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:

The project model (from earlier) with a squiggly line showing progress towards execution.
the line wiggles between alignment and execution a lot.

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.

Momentum is your friend (and can be your enemy)

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 project model (from earlier) with black stains on it. Stains that are within a single
stage are labelled 'Local Problems'. Stains that cross across two stages are labelled 'Regional
Problems'. And there's one stain that impacts all three stages and this is labelled 'A Global

Local problems 🔥

Local problems are contained within one stage of the project and aren’t (yet?) impacting another layer. Both cause and consequence are contained within a single stage.

Examples include:

  1. Disagreements about the technical approach to a feature (all within execution)
  2. Miscommunication between departments about impacts before feature is developed (all within alignment)
  3. Tension between key programme stakeholders about prioritised benefits in the proposition layer before the project is green-lit! (all within proposition)

Local problems can look and feel really big, but they’re relatively easy to solve. And momentum really works in your favour when sorting them out.

When a problem is local, it’s easy for everyone to see both the problem and the impacts of it because it’s all within one frame. Because they’re local, the cause is usually within control or easy reach of the people on the ground. That makes it easy to spotlight them, get attention, and sort them out.

And since you already have momentum and a direction, local problems are the equivalent of changing lanes – a short detour perhaps – but you can continue on your way towards the goal.

If the problem is local, momentum is your friend. But for bigger problems, momentum can be far less friendly …

Regional problems 🔥🔥

Regional problems have spread. They are no longer contained within a stage and are already impacting the downstream stage. Or more likely you’re the unlikely schmuck who is downstream and dealing with the consequences.

Examples include:

  1. Disagreements about the technical approach to a feature due to underlying tension about how a platform is funded and supported, or miscommunication between departments about impacts during feature development! (issue in alignment has spread into execution stage)
  2. Tension between key programme stakeholders about prioritised benefits in the proposition while the solution is being designed (issue in proposition stage has spread into alignment stage)

These problems are harder to solve.

First off, it is super easy to misdiagnose the issue as ‘just another local problem’ to be sorted out because the cause isn’t in the same frame as the impact. This is compounded by the fact that you are oriented away from the underlying (upstream) cause.

And while dealing with the symptoms can work, it is usually just a temporary fix. The issue will reoccur unless you sort out the cause.

The real cause is in the previous stage. This means that to solve the problem, you need to trudge back up towards why. And momentum is far less friendly when you have to move against the flow.

In fact, not just unfriendly, it can be downright hostile.

First you need to have the time to hike upstream to identify the actual cause. Then, you need to surface the problem and build consensus about sorting it out before it does more damage. And to do that, you probably require at least some of the people on the ground to divert attention away from the goal for a short bit, as well as help and support from people who aren’t in the current picture at all!

Because of the momentum, sorting a regional problem can be the equivalent of attempting a U-turn on a busy street. Unless you’re Vin Diesel’s stunt double, that’s hard to nail.

Global problems 🔥🔥🔥

Global problems impact all the stages. The proposition isn’t sound, alignment wasn’t done, and you’re already in build.

An example: Tension between key programme stakeholders about prioritised benefits in the proposition while the solution is being designed. This leads to conflict and miscommunication between impacted departments and a compromised solution being selected and green-lit. The implementation team have started executing against the compromised design.

No one is happy. Everything is on fire. This problem is much harder to solve. Global problems require bigger guns than a business analyst carries.

If you discover a global problem, my honest advice is: escalate and then get the hell out. Any momentum you have is false, because the goal doesn’t make sense.

Sometimes simple is better!

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?

Hey, tell me what you think!

Please do hit me up on LinkedIn or by email if you have any feedback! I’m always up for difficult questions, and I’d love to know what you think of this article!