Introduction

A Fountain in Old Town

I’m writing this from a coffee shop in the Old Town of Stockholm, Sweden (in Swedish: “Gamla stan”).

Old Town is an architecturally-preserved neighborhood that lives up to every romantic, sentimental notion Americans have of “Old Europe.” 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 onto 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 in.

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 through which I want to navigate. After all, every cobblestone street looks the same from up close.

I’m the founding partner of a digital agency called Blend Interactive. I handle most of our sales, and I usually take inbound and introductory phone calls from people looking for our services. Blend specializes in content management. That’s why a lot of people call us. But more and more, questions were “leaking” out of the CMS implementation into the larger, broader project.

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, 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:

  1. Very rarely does a project fail for technical reasons.

  2. 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.

– Deane Barker


On Writing A Book I Can Believe In

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. 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.

There’s nothing about a project plan that 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, the entire concept of taking on 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 wipe away some of that gap.

And now here I am. Documenting that process. Like I never wanted to do. Writing something that will someday become a book, all to help the people I work with every day. 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.

- Corey Vilhauer


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 every one 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

When the idea for this book started to form, we wondered how we could best get the information across. It’s not enough to simply spill it out on these pages. That doesn’t make any difference unless it gets absorbed and ultimately used by the reader. We will follow some simple principles:

  • Lessons of shorter length

  • Links from each lesson back to the larger process and the other lessons, so you always knows where something fits into the larger picture

  • Lessons examined from multiple perspectives

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. You can always open a book and reread something. The key is knowing what information is relevant to your current situation, and where you are currently in the process, relative to the process as a whole.

This book breaks down the project process into 26 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

This is the summary of what the chapter is about. It will be 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?

This focuses 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

This is the main information of the chapter, describing the phase in detail. We tried to keep this to something that could be read in 7-10 minutes. Since the average reading speed of a college-educated adult is 350 words per minute, that gives us an average of about 3,000 words to work with. In a perfect world, you’ll be able to read a chapter every day and absorb the information in it fairly quickly.

The Big Picture

This is 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. Could this be happening at the same time as something else? What phases earlier or later in the process could have an impact, or be impacted, by this phase?

Application

This is a short examination of whether or not this phase applies to your situation. When can it be safely skipped?

Inputs and Outputs

This details both what you need going into – and what you get coming out of – a particular phase. This comes in two forms: actual deliverables or “artifacts” (think: files or documents), and alignment (think: official decisions, stakeholder agreement, and forward movement). What inputs inform this phase, and what will be generated as a result of this phase?

Staffing

This examines the humans behind this phase. What type of professional completes this work? And importantly for some organizations, if you don’t have this person in-house, how easy and appropriate is it to outsource this work? What type of firm or consultant might you be looking for?

Resources

This is where you can go to dig deeper. Formative articles and conference presentations – and often entire books – have been written about each of these subjects. If you want to dig deeper, what are some available resources?

Other Voices

This is where some of our friends from the industry will chime in to provide anecdotes about their experiences, both good and bad. Knowing what someone else has seen, or the mistakes they have made, will give you some perspective on where you might go wrong or do better.


On Adaption

The military has a saying:

No plan survives contact with the enemy.

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 just 25 years old and still evolving rapidly. Technology is changing, 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.

Our company has been working through these projects in one form or another for almost 15 years. We don’t claim to have every answer, and no process is set in stone. But the steps we outline in this book represent what we do to 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.