Introduction
A Fountain in Old Town
By Deane Barker
I’m writing this from a coffee shop in the Old Town of Stockholm, Sweden (in Swedish: “Gamla stan”)1. It’s full of narrow, winding cobblestone streets, tiny alleyways, and artisanal shops. You can wander for hours in abject wonder at architecture from the 13th century, then stumble into quaint little courtyards or bustling town squares. You can point your camera in any direction and capture a postcard.
It’s also really easy to get lost.
I swear I’ve passed by the same stone fountain four times now, but I couldn’t find it again if my life depended on it.
This is why I’m sitting in this coffee shop. The promise of free wifi persuaded me to duck in, buy a cup and a croissant, and spend a few minutes on Google Maps trying to figure out exactly where I am.
Google Maps is great. It elevates you above where you are. Instead of tight little streets, I can see an overhead view, with my location clearly marked. I don’t get the nuance of standing in front of that gorgeous fountain, examining how the vines have grown over the façade and listening to the water splash through it, but that’s not what I need right now.
The key is context, or “the circumstances which form the setting.” From street level, I can look around and know my immediate surroundings, but that information is useless without a larger understanding of where I am in relation to the overall structure that I want to navigate. After all, every cobblestone street looks the same from up close.
I was the founding partner of a digital agency called Blend Interactive. During my time there, I handled most of the sales process, and I was a part of most of our inbound and introductory phone calls. Blend has always specialized in content management – that’s why people would initially call – but no matter what specific topic we began a call with, most conversations eventually turned toward questions about the larger process. The transition phrase would vary, but generally sounded something like this:
- “I’ve been asked to redo our website, and I’m not sure where to even start.”
- “We’ve done some work on this already, but I don’t know how far along we are, or how our current situation fits into your process.”
- “Where do we go from here? We know where we need to get to, but we’re not sure of the exact steps.”
- “Once the website is built … then what happens?”
A year after my first book was published — Web Content Management: Systems, Features, and Best Practices — I started putting together a talk entitled “Why Content Projects Fail.” I gave this talk at various conferences seven times around the world that year.
Among the points in it were these two:
- Very rarely does a project fail for technical reasons.
- You need to plan your project from the absolute beginning to the absolute ending, and those two points are much farther apart than you think.
In looking back, my first book really didn’t address these two points at all. It was about the technical parameters of content management systems and how they’re implemented, which means it addressed only a small slice of a full project. The true lifecycle of a project begins far earlier and ends far later than what I covered in the book.
Indeed, one of the lines from my talk was:
Your project begins the instant someone in your organization says, “You know, we really should do something new with the website.”
Strict CMS implementation projects are easy by comparison. The larger process is more vague, and too many people find themselves completely adrift with no idea what stage they’re in, how far along they are, or where they’re ultimately trying to go.
Kind of like an American tourist who keeps wandering by the same fountain.
Navigating anything – be it Old Town Stockholm or a web project – is a matter of context switching. You need to frequently switch between an overhead perspective with less detail and a “feet on the ground” perspective where you can absorb every last nuance.
It turns out that Old Town is actually an island. Its perimeter is pretty clear against the water. From satellite view in Google Maps, I can tell where I am compared to the larger whole. I can see Old Town from edge to edge. I might lose some of the details, but there’s no doubt that I can take in the whole of it.
Armed with this information, I can set out again and stop walking in circles. But, first, coffee.
On Writing a Book I Can Believe In
By Corey Vilhauer
I have a folder on my desktop that includes treatments for three different books. One is a proposal to Continuum’s 33 1/3 series (now published by Bloomsbury) about Ween’s Chocolate and Cheese, a seminal weirdo album from a seminal weirdo band. (This one ended up being written, but not by me. Instead, some guy named Hank Shteamer got the honors.)
One is a series of completely unfinished and unrelated short stories based on … (once again) the songs of Ween’s Chocolate and Cheese.
The last book treatment is about structured web content. I never wanted to write that one, really.
To be honest, I never wanted to write about work. I didn’t know where I stood – where I could fit in, and who would listen, and why I had the audacity to consider it in the first place. I ran out a greatest hits of “imposter syndrome” excuses and then dove back under my desk. I struggled, because I had no confidence. I was scared of not doing things correctly.
I found myself falling back to when I started at Blend, when I was a fledgling strategist creating a content strategy practice from scratch, and Deane — out of nowhere — threw a lofty ultimatum my way: “You will give a talk at some conference by the end of the year or you’re fired.”
To this day I assume he was kidding, but it didn’t matter. I reached that goal — in 2011, I was invited to speak at Confab, the leading conference on content strategy, and I found my people. I found a group of people who did what I was trying to do. I found the niche that so few of us ever find: the balance between doing good work and doing satisfying work.
But more than that, I found out that I wasn’t the only one who wondered where they stood.
I found that everyone is on a different spot in their journey. For every person who has helped build a site, there are hundreds who are just beginning and thousands who have never even thought about it.
Now, as director of strategy at Blend Interactive, I’m often the first person people talk to after the project’s been sold and scheduled. I’m the person who jumps in with big promises of hope and change pointing toward a magical future on the web. However, as a part of that process, I’m also the one who has to start setting expectations and dashing dreams.
And I answer a lot of questions.
Nothing about a project plan makes sense when you first encounter it. The larger an endeavor, and the greater the number of moving parts, the harder it gets to know when you’re being bamboozled. The gap between those who know and those who don’t know is wide and complicated and, honestly, a little scary for a lot of people.
I don’t think I’m being cute when I say “scary.” If you care about your project being a success, you’re probably scared of something.
For many, including those of us who have been through dozens of successful implementations, a web project is a frightening and overwhelming disaster waiting to happen. It’s a different way of thinking – a different glossary of terms, and a different model of concurrent processes. It’s even a different idea of space, especially for those familiar with a more traditional means of marketing and communication.
So when Deane approached me with the idea for this book, I knew this was something I could write. Not because it was going to set the world on fire through some kind of transformative paradigm shift, but because it was going to help bridge some of that gap.
This book is designed to help people who are in charge of a new project that lives outside of their domain, in a world where things change all the time. People who just need to know enough about the web process that they can make informed decisions, sure, but also people who just need to know they’re going in the right direction in the first place.
People who are tasked with creating an in-house team and don’t know where to start. People who are joining larger web development teams and need to know how they fit in. People who are struggling to find their place in the industry, who just know there’s a part of the web process that speaks to them.
More than anything, we hope this will bridge that gap – to bring the concepts and ideas of a web project closer to reality.
You’re not going to come away knowing how to lead a two-day discovery workshop, or spin up a Wordpress install. But hopefully you’ll come away feeling more comfortable – both with the people you are trusting to make your web project happen, and with yourself. More comfortable, and a lot less scared.
What This Book Is About
This book is a broad survey of the entire process of planning, executing, delivering, and maintaining a web project. By “web project,” we mean something on the spectrum of projects involving the creation, redesign, or reconfiguration of a website.
A key goal of this book is breadth rather than depth. For many of the steps we’ll discuss, dozens of complete books have been written, and our goal is not to duplicate their content. Just like a map gives you an overhead view without nuance, this book will show you the major structures in a project so you can get your bearings. We’ll leave it to others to dig deeper into each step.
How This Book Is Organized
In The Design of Everyday Things, Don Norman’s book on industrial design, he talks about “mental models,” which is how a user thinks a device works. The usability of a device is enormously influenced by how a user thinks about it – how they assume it works.
One of the keys to making a device usable, it turns out, is to improve the user’s mental model. To make it more clear. A glimpse into the inner workings of something is key to understanding how pulling lever A makes widget B do something.
Our goal for this book is to impart a mental model for the overall project process of building a website from the bottom up. It’s less important that you absorb everything from every lesson, and more important that you understand the framework.
This book breaks down the project process into twenty-four phases. They’re presented here in roughly chronological order, but the process is only vaguely linear, so some phases will occur out of order or at the same time as others. Additionally, not every project is the same, so some of these phases might not occur at all. Indeed, part of the process is to determine what you actually need to do.
Each chapter is organized as follows:
- Summary: A few sentences describing what’s in the chapter. Review these at the start in order to begin with the total context in mind and understand the breadth of it all.
- Does This Apply: Focusing on whether or not your project needs to worry about this phase. For a start-to-finish project, there’s a great chance that every chapter will apply in some sense. However, this is not always the case.
- Main Narrative: The main information of the chapter, describing the phase in detail. We tried to keep this to something that could be read in fifteen minutes. We may or may not have succeeded.
- Inputs and Outputs: What you need going into – and what you get coming out of – a particular phase.
- The Big Picture: A discussion of where this phase fits into the larger process — the context of this chapter in the larger web process – and where it fits relative to other phases.
- Staffing: This examines the humans behind this phase. What type of professional completes this work? Should I outsource this?
On Adaption
The military has a saying: No plan survives contact with the enemy2.
Digital projects are complicated. They have a lot of moving parts happening both serially and in parallel. They combine social, emotional, and technical aspects of your organization and the people working in it. And they touch many different groups, each with their own agendas.
Furthermore, there is no Grand Unified Theory of anything in this industry. Remember that the web is only a few decades old and still evolving rapidly — as are the processes and best practices used to deliver it. The leading edge of any industry is blurry and subject to argument, and no standards are really settled until a technology or practice falls far enough back from that leading edge that its evolution begins to slow down.
Put another way: nothing is settled until it’s boring. If something is exciting, fresh, and innovative, that only guarantees that people will argue non-stop about the best practices for implementing it. Thus, any book purporting to show you “the process” is, by definition, simply one opinion.
The steps we outline in this book represent what we have done to help bring some order to the larger domain and to ensure the process remains as open and clear as reasonably possible.
To execute on the lessons in this book, you’ll need to adapt and set priorities. You need to understand the big picture, know what’s on the critical path, and know what work can be shortened or jettisoned entirely when the timeline gets tight.
No project is perfect, and the results are analog, not binary. When you look back on a project, it’s not evaluated in terms of “success” or “failure,” but rather on how close you got along a spectrum toward some unattainable definition of “perfect.” Some projects get closer than others, and you’re often striving to simply cross some vague, self-imposed line of results that justifies all the work.
In the end, your goal is to improve your current situation to the greatest degree possible. Let’s get started.
