The Alignment Model: 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 explained 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.
Now 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.
Here I 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.
Warning
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, if so, then please note that this article will be unhelpful to you!
Introduction
The model is basically as simple as Frank’s original sketch, although 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 moment when you realise that essentially I’ve simply repackaged ’s Start with Why’s Golden Circle and applied it to projects. No shame — guilty as charged! And I am not at all sorry because you are likely already familiar with Simon’s model, so the cognitive load of introducing yet another model into your brain is lessened. I call that a 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. Why do you think that we call it the Alignment model rather than the Execution or Proposition model?
If alignment covers everything from the business case to the implementation, then EVERYTHING is in here. In simple environments, alignment might be a breeze, but 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 exactly how to do the thing before simply doing it. 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 is much that you need to align before you start building or implementing changes. And there’s actually no single right way to do this. The MVA (minimum viable alignment) depends on the complexity of the environment. You should pick a path that fits the context.
No matter what path you do choose to follow to gather the necessary alignment, I cannot overstate the importance of doing alignment and doing it well. What happens in this stage has an oversized impact on the end result of the project. It is where the real heavy lifting happens.
But let’s get back to the model …
Where to begin?
Well, at the beginning, of course!
Ideas move from proposition through alignment and out into execution. That’s what the big arrow is all about! And 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 that 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 is always some level of alignment, and there is always some amount of execution. If the project doesn't get shelved, that is.
While I’m sure that 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 or equivalent!
It doesn’t matter whether 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 it’s 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 should be doing just enough alignment to build the next thing. Working through the model using an iterative approach would look like this squiggly line diagram.
And arguably, just enough alignment should be the approach no matter how small (or large) your delivery chunks are. You want to bake — 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, but it 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 that the org around us is aware of our work and that it 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.
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:
- Disagreements about the technical approach to a feature (all within execution)
- Miscommunication between departments about impacts before feature is developed (all within alignment)
- 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 your control or within easy reach of the people on the ground. That makes it easy to spotlight the problem, get attention, and sort it out.
And because you already have momentum, local problems are the equivalent of changing lanes — a short detour perhaps — while you continue on your way towards the goal.
If the problem is local, then momentum is your friend. But for bigger problems, momentum can be far less friendly …
Regional problems 🔥🔥
Regional problems have spread across a boundary. They are no longer contained within a stage, and are already impacting the downstream stage. Or, more likely, you’re the unlucky schmuck who is downstream and dealing with the consequences. Examples include:
- Disagreements about the technical approach to a feature because of underlying tension about how a platform is funded and supported, or miscommunication between departments about impacts during feature development! (An issue in alignment has spread into the execution stage)
- Tension between key programme stakeholders about prioritised benefits in the proposition while the solution is being designed. (An issue in proposition stage has spread into the alignment stage)
These problems are harder to solve.
First, 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. While dealing with the symptoms can work, it is usually just a temporary fix. The issue will recur 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.
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, while also getting 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 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 most of us carry.
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. What good is momentum if you're heading off a cliff?
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 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 point of a model: to eliminate unnecessary detail so that 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?
Last updated .