Chapter 1

Know the Scope of the Project

Summary

So, we need a new website? The easy question is, “Now what?” The harder question is, “How did we get here?” Gain buy-in on the reasons behind a new project, define the problem in a way that gains traction, and avoid some early red flags along the way.

Does This Apply?

Every chapter following this one was written, in part, as a response to the universal desire for a new web project. This is where it starts: a proclamation, a dream, a spark. It isn’t whether or not this stage applies to the web process, it’s that without this stage there is no web project.

Narrative

“We need a new website.”

It’s the sentence that sets dozens of potential traps in motion. It’s specific, yet frustratingly vague. It’s just five simple words, but it’s the first step in what could end up being months – years, even – of organizational turmoil.

Or, it could be the start of something brilliant. It could lead to an increase in sales unlike anything your organization has ever seen, or it could be the catalyst for a long-overdue brand refresh.

It could be the best of times. It could be the worst of times. All we know now is that there’s a lot to tackle. And that shouldn’t come as a surprise: the web presence for your company or organization is one of the most visible and important communication channels you own, and taking the process lightly is a surefire step toward disaster.

But how did we get here in the first place?

Episode 1: Know the Scope of the Project (w/ Bill DeRouchey)

Corey and Deane discuss the opening beats of a project. Then, we chat with Bill DeRouchey, former lead product designer for Zendesk, to discuss his history with vetting and researching a new project during the opening salvo, territorialism, and Mike Watt.

28:38 | Bill DeRouchey

Past Episodes

The Initial Spark

Though the machinations of decision-making might feel like a signal from some far off place, web projects don’t come out of nowhere. If you’ve been tasked with a web project, there was an originating event or condition. This is either a chronic issue percolating over time or an acute situation (sometimes a catastrophe) that’s forcing change.

Here are some reasons we’ve seen for embarking on a web project: 

  • A desire to change the underlying architecture of the website. To move from on-site hosting to “the cloud,” to switch hosting providers, or to use a programming language or framework more compatible with the organization. 
  • The CMS (content management system), or a specific version of the CMS, is no longer supported by the vendor, and switching or upgrading will require a complete rebuild. 
  • A desire to use or incorporate some technology into the website – personalization or A/B testing, for example – but it just can’t be done with the current platform. 
  • The organization would like to engage with an external marketing firm or agency, but that firm has no experience with the current CMS or programming framework.
  • Personnel changes at the organization have brought in new decision-makers with a different perspective of how the website should perform.
  • Visitors or employees continually complain of being “unable to find anything.” 
  • The technical underpinnings or content architecture of the website are dated, and there’s a lingering feeling that valuable business content is being stored in such a way that future retrieval and use would be difficult.

Maybe one of these represents your project. (Bonus points if you can claim more than one.) Situations like this are what we call the initial spark. They are the key moment in which opinion turns toward creation of a new web project. But they rarely exist in isolation. 

While these sparks are usually tied to web functionality, many times they reveal other problems. People inside the organization sense “blood in the water,” and they see the impetus for change as an opportunity to improve other areas. 

Announcing that your CMS is no longer supported and will have to be replaced might be met with groans from IT, but cheers from marketing because “we never liked that thing anyway.” Meanwhile, the finance department is saying “find a cheaper one next time, because the subscription costs are killing us” and the director of sales is thinking “maybe now I can get a website I’m proud to show to prospects.” 

In the end, there’s rarely a single reason why these projects start. There’s just an acute event or situation – a spark – that kicks off the entire project, like a snowball down a hill. As it rolls, it grows larger and larger, until it stops at the bottom and lays bare dozens of reasons why the organization wants to make a change.

The Role of the Website

Of course, it’s one thing to act immediately on a spark. It’s another to take a step back and understand the landscape of your potential web project. This often goes higher than the web project itself, into the sometimes hazy world of business goals. It also means understanding not just the reason for the new web project, but the reason for the website itself.

First and foremost, understand that your website is a tool. For most organizations, it’s a communication tool. It’s one (or more) of dozens of connection points in an organization’s outward appearance, which means it must be built to function as such. A well-built, communication-focused website places message and content at its core, and it is responsible for delivering both within your organization’s brand standards.

Websites are created for the following reasons:

  • Information: Your organization holds some kind of information – whether this is a definition of a process, or a list of university programs, or maybe even your company’s history – and you would like that information pushed out to the world.
  • Commerce: Your organization has something it wants to sell. This could be widgets or fidget spinners, or it could be something like professional services or streaming video. Regardless, the end purpose of a commerce-focused site is to get money from the person who visits.
  • Entertainment: Think of this as “content as the end goal.” Reading short stories, watching videos, or commenting on the most recent Wrestlemania main event all fall under entertainment. (And, of course, entertainment usually exists solely to make advertising easier to sit through.)
  • Persuasion: While this seems to go hand in hand with commerce, it can also persuade in a non-monetary way: a political candidate’s website, a local initiative, or a non-profit looking for volunteers all display characteristics of persuasion without being explicitly tied to commerce.We address that here in a second, just be patient.
  • Administration: Paying for your vehicle licenses, applying for a job through an online job search application, or registering your Nintendo account – these are all ways in which a website can provide access to administrative tasks.

Some sites focus on only one thing, like how a writer’s blog might be focused only on providing entertainment without any ties to advertisements or newsletter sign-ups – a true vanity project. Most sites are going to focus on more than one thing, like how a political candidate’s website both tries to inform you about the candidate’s issues (information), give money to the candidate’s campaign (commerce), and ultimately vote for their candidate (persuasion).

Sometimes you end up with all five purposes, and then you’re really cooking. For example, Netflix offers streaming video (entertainment) for a cost (commerce) with sections of the site focused on both convincing you to sign up (persuasion) or on getting your service to work with your smart TV (information) as well as facilitating your existing account (administration).

Knowing the role of the website is more than just knowing if it’s going to have a shopping cart or not. Websites and web projects are made up of dozens – and, at times, hundreds – of different layers and moving parts, each one building off of the last, each one looking toward a final finished and stable product. And this is the very base layer of the project: what at its core is this web project hoping to become.

The spark is enough to get that snowball rolling. But whether you run into any trees on the way down depends on whether you’ve determined a proper path and purpose.

Knowing Your History

Whether or not this is the first web project for you, it’s probably not the first time the concept of a website or functionality update has crossed the mind of leadership.

There’s history in every request for a new website or request for new functionality. There’s history, and there’s politics, and there’s organizational strife. This is not always bad. But it’s always there, and it needs to be addressed early in the process.

Ask Questions

We have a spark and we know the purpose, but we don’t have the full picture. What deep-seated treasures are we about to unearth? What old fires are still burning, and which of them are going to flare up and cause complications?

We don’t know. In fact, in most cases, no one knows. As organizations get older, the issues of the past – the fights over logo design, or the reasoning behind certain navigation terms, or the separation of departments – are lost. They are scars with a forgotten origin; we’ve had that mark on our arm since we were a kid, but we no longer remember how it got there, and so we live with it and move on.

These issues compound over time. One small decision made in a huff as a marketing director threw their hands in the air with a, “Fine, we’ll do it your way,” can become a doctrine that’s built upon for years, until no one can remember why the decision was made in the first place.

So it becomes important to pull these decisions to the surface, at least enough so we don’t run full speed, blinded by the spark, into another failed project. One technique that’s proven wildly useful in our content strategy practice is actually devised from the automotive industry: The Five Whys.

Developed by Sakichi Toyoda and adopted as a major part of Toyota’s lean manufacturing model, the Five Whys directs you to ask why – or, more specifically, “how.” A lot.

First, you define the problem.

Problem: We need a new design because this one always looks broken.

Then, you ask why until you get further toward the source of the pain.

  • Why does it always look broken? Because there are too many links at the top of the site and it breaks at certain mobile widths.
  • Why are there too many links at the top of the site? Because we have to list all of our audiences at the top of the site.
  • Why do you need to list all of the audiences at the top of the site? Because students, parents, and faculty all get served different content.
  • Why do they get served different content? Because we have different departments that relate to each of those different audiences, so they write their own content and some of it

… and on and on and on, until (often) we see that those sparks are actually thrown not by the design, but by the underlying governance model, or by an outdated site purpose, or by an insistence on creating content unrelated to the organization’s business goals. This may not change the ultimate goal – a request for better product pages might still be a request for better project pages – but it will give you a lot of insight into why the spark shot off in the first place.

Heed the Red Flag

It might have been a surprise for Sue Hendrickson, paleontologist, when she stumbled upon “Sue,” the largest and best preserved Tyrannosaurus rex ever discovered, but it wasn’t because she didn’t know what to look for. It was immediately recognized and pounced upon.

“Anybody who had any idea what a fossil versus a rock (looked like) would have seen it,” Hendrickson said. “There (were) a lot of broken bones dribbling down (and) about eight feet up the side of the cliff, there were three articulated vertebrae and a couple of other pieces of bone sticking out.”

Knowing what to look for when digging into the history behind a new website will help you uncover more than just some vertebrae or broken bones – ultimately, you may start seeing some project red flags that are necessary to understand and navigate as the project moves forward.

Red flags like:

  • A project built around a new technology without reference to an actionable business goal, or “I really think we need to integrate with ”
  • A mandate built upon a competitor’s new initiative rather than your organization’s mission or vision, or “If ABC is doing it, then we should be doing ”
  • A drive to change focus due to the vocal minority of a specific department, or “Our sales team feels like a mobile app is the best way to ”

These red flags all have one thing in common: they are reactionary. They are rooted in a desire in change for the sake of change. They are real, and they are important to identify.

But not all of these red flags can be avoided, nor do they necessarily predict project failure. Instead, these are points in which clarification of scope – and at times a narrowing of purpose – needs to become the first order of business, with increasingly managed expectations not far behind.

Red Flags for Stakeholders

Red flags don’t just come up within a project’s scope – they also sprout up among the people who make up the leadership of a project. Project Management for Humans, a book by Brett Harned, goes in-depth with a list of red flags for project stakeholders, including:

  • Stakeholders or team members who have no interest in talking about how the project gets done
  • Stakeholders who invite everyone to everything
  • Stakeholders who want too much in too little time
  • Stakeholders with a tendency to gossip

If you immediately see an overlap between this list and the last, you are not mistaken. Red flags within projects occur when red flags within people show their face.

The Project Charter

When we come down to it, we need to formally determine a reason for the project to move forward – one that everyone can agree on, one that can secure and maintain a starting and ongoing budget, and one that can be embraced by leadership as a real initiative.

This reasoning, and the document that forms around it, is often called a “project charter.” A charter is the authorization you have from the organization to spend money and task resources in pursuit of an agreed-upon goal. This document is less formal than a project plan, but it explains, in broad terms:

  • A description of the project
  • The goals the project is trying to achieve
  • A description of the budget, both in amount and source (from whose budget the funds are being drawn)
  • An explanation of project authority and accountability
  • A description of the planned or assumed return on investment
  • Some expectation of schedule

Notice that we’re still very high level. There’s no discussion of team members, implementation phases, or what content management system we’re moving to (unless, perhaps, a forced shift to a particular CMS is the only point of the project). The purpose is not to outline every stage, but to will the project into existence so that next steps can be planned.

Charter, Scope, and Plan … In Our Words

This and the next three chapters can feel a little loosy-goosy, so let’s clear some things up about how this is organized.

We will often refer to three specific stages of project planning: project charters, project scope, and a project plan. While there is some discussion within the project management world as to what these three concepts entail – you’ve already read about the project charter above, and you’ll encounter the scope and plan in future chapters – we are not naive enough to believe every project is going to fall into strict adherence.

In our experience, charters, scopes, and plans often blend together depending on the makeup of the project, the urgency of the project, and the level of familiarity and comfort within the project team. The three form a spectrum of project initiation. Instead of things, we see them as framing devices.

  • Project Charter: the formal (or informal) declaration that a project is to begin, and what general goals that project is designed to tackle. You are selling the project at this point, in a sense, and as Simon Sinek points out in his book Start With Why, a charter effectively communicates the why part of a project. Without the charter, the scope and plan are listless and directionless.
  • Project Scope: what we are going to do at a section-by-section level. For example, project scope could include a list of templates to be designed, a list of technologies to implement, or a list of requirements to meet. This is the what part of your project – it tells us what to expect, but not necessarily how to reach it.
  • Project Plan: how we are going to tackle the scope. For example, the plan might include a list of sprints and project deadlines, a manifest of who will work on the project and what roles they will take on, or even a more narrative list of requirements. This is the how part of your project, and it tells us how to do it and why it matters.
  • We promised that items in this book would sometimes occur independently (and concurrently) with each other. This is a prime example of that. It’s not unheard of for a project scope to depend on the project plan. It’s common for the project plan to require tasks discussed in later chapters, such as an inventory or discovery workshop.

Unfortunately, there is no perfect, correct answer. Whatever works for you – whatever gets you closer to your goals – is as correct as you can expect.

Note that specifying hard requirements in this document is tempting but illusory. If all it took was writing things down, we could decide we wanted every feature available by next Tuesday, for $1.98. Wouldn’t that be lovely?

To recap, here are some questions to consider for this phase:

  • What happened to cause this project to come about?
  • Who is asking for the change? How far up the org chart does the directive go?
  • Where are your organizational points of pain? Conversely, what are the business goals you would like to bring about?
  • What issues are hiding below the surface?

And, finally, when discussing a new project with a potential customer, I always close a discussion with the same clarifying question:

Six months after this project has ended, what has to have happened for you to think the project was worth doing?

If you can only answer one question in this phase, make it that one.

Inputs and Outputs

The only input to this phase is the mandate to get started. Someone in your organization should have given the directive to get the project underway, and you should have some level of executive mandate or backing. Part of this phase is documenting that mandate.

The output of this phase is an approved project charter, which is a document that explains the scope of the current project, the business goal, and where the mandate comes from, and it may also include things like an available budget or estimated schedule. This charter should be reviewed and approved by the powers that control (1) the budget, (2) the internal human resources you will need, and (3) the website under scrutiny.

When this is done, you have achieved some organizational consensus of what the problem is and some high-level direction on how you’re going to go about fixing it. Congratulations, this is a big step.

The Big Picture

This is the foundational phase from which everything grows. You need to do this in some form before you do anything else, but know that this might not be a formal process.

While a written project charter is clarifying and it gives your organization a document to rally around, many projects have been started through a series of informal conversations. Those projects did this phase and ended up with a tacit project charter of sorts – everyone sort of agrees on what needs to happen and what the constraints are – but it wasn’t codified anywhere, so there could be disagreements about it later.

In fact, some projects are completed satisfactorily and only in retrospect would the team realize they completed this phase informally and without committing to it or formally codifying the results.

Staffing

The spark could come from anywhere, but the research into that spark – and understanding the history of why this project came to be and where it might go – is going to lie with some major stakeholder, and that research could include anyone from a long-time employee to a former board chair to the people who walk into the store every week.

Resources

Articles

Books