Don't defer complexity

The biggest train wrecks (see image on page 44 of the free version 1 or page 65 on version 2 of Website Migration Handbook) I have witnessed on projects occur when complexity is deferred. And this happens a lot. Some examples of deferred complexity that I have seen result in significant, late problems (in many cases multiple happen in a single project):

• Integration. Integration with other systems is started toward the end of a project, and the integration is more difficult than anticipated (although isn’t integration usually tougher than anticipated?).
• Non-technical. The complex part isn’t the technical stuff at all (again, which is usually the case), but the non-technical parts aren’t considered until the very end when it is too late to get true buy-in. But often the team’s concentration is on the technical bits, and then when it comes time to do the hard stuff at the end the project derails. For example, if the goal is to have more distributed content entry there is a heavy dynamic between non-technical and technical issues, and their involvement cannot be deferred until the end of the process if you want successful distributed content entry.
• Scale. Sometimes the real issue is how the digital change will scale, and considering this late means problems scaling. For example, sometimes the real problem is how to engage everyone for a global rollout. Without considering this early, perhaps the “enterprise” CMS is only used by the central team.
• Migration. Alas, often the migration is an important part of a project to ensure that the content works. If this happens late then many problems can occur, such as the content not actually fitting within the templates that everyone hinged their hopes on.

Let me clarify that I am not arguing for more complexity. Of course the simplest solution that satisfies business goals is best. But almost every project does have complex elements, and big issues arise when these difficult bits are put off to the end.

In general, complexity should only be added where it will structurally improve your digital presence.

Some of the highest-impact digital changes you can make are hard. This isn’t for the faint of heart. For instance, perhaps a key requirement of a project is consolidating data from multiple sources to present a comprehensive view that no other organization can match. In that case, that complexity is certainly important. The fact that it is both complex and important means that this should be started early.

Why deferring complexity is a problem

Aside from the broad statement that deferring complexity often leads to train wrecks, what are some problems with deferring complexity?

• It hides important discussions.
• It disallows the possibility of cleanly degrading the vision or reframing the problem.
• It leads to not meeting expectations (or delaying the project).
• It makes meeting business objectives less likely.
• It does not allow separating out what is easy from what is important (the easy stuff gets done).

Let me stop again on that last point. I am all for iterative development, and argue for ongoing change which I also wrote about in the book Website Product Management. So the point isn’t that we should complicate things but that maybe it’s more important to tackle the hard stuff earlier, even if it means not doing tons of easy stuff in any particular time period.

Why does this happen?

In general, people have a preference for the concrete (such as how will one specific page look). That’s something we can all get into a heated argument about. But the more complex stuff is harder to get your head around: how will the content appear on this page, how much will it look like the page next to it, how will people enter content in the backend, etc. In other words, there are a lot of things that are easy to state quickly (and for people to understand at some level) but difficult to implement well! In addition, the concrete stuff feels like making progress earlier.

How to avoid this:

Although I wouldn’t say that avoiding all the above problems are easy to resolve, there are two things to do:

• Engage with complexity earlier
• Meaningfully reduce complexity where possible

Engage with complexity earlier

There are many stages where you could engage with the complexity:

1. On a day-to-day basis when discussing issues and opportunities, to immediately bring complexity into that discussion
2. When setting the vision for a project (far before the RFP is sent out — see From vision to use cases for selecting a CMS)
3. When sending out the RFP
4. When kicking off implementation (see Hardest or easiest? Move toward the compelling vision)
5. Steering during implementation (remember that whatever anyone says, seeing the complex parts work is the only way to be sure, so even during implementation see the complexity as early as possible)

Complexity should be dealt with at all these steps.

Meaningfully reduce complexity

The goal isn’t to just reduce complexity, but to do so meaningfully. In particular, we need to differentiate between what is easy and what is important. We have to avoid the temptation for short-term thinking here, since we may actually increase the complexity on some less glitzy change now (and perhaps decreasing the complexity on some of the wow factor items) in order to make important and broader change.

There are at least two ways of reducing complexity meaningfully:

• Deferring complexity entirely. If we engage with complexity very early, we can look at all the complex bits of what we would like. By prioritizing it, we can decide which complexity is most important and potentially defer some complexity entirely until another phase (download a flowchart for handling change requests).
• Implementing a focused bit of complexity. As they say, there are many ways of skinning a cat. For the complex parts of the project we can break down the problem to think in terms of how deeply the capability could be implemented (which will also be the topic of an upcoming article). It may be possible to implement 80% of the functionality with 20% of the effort if we plan it early enough, and then we can iterate improvements over time.

In summary, we should always be engaging with the complexity as early as possible, and meaningfully reducing complexity where possible.